Re: Comments on pmake diffs for building on Linux
On Wed, Mar 05, 2008 at 03:03:44PM -0500, Chuck Robey wrote: >I bet a very large portion of those among us who are professional codes >have had been forced at some time to port our make, whether it was the >original pmake, or the up-to-date version (I did the most up to date I >could manage. I looked at porting pmake to Tru64 about 9 years ago and rapidly decided I couldn't justify the effort (I only wanted to port a couple of FreeBSD utilities) and re-wrote the relevant Makefiles. I applaud Warner's efforts here as increasing the portability of FreeBSD utilities is very worthwhile. >The politicians amongst us will kill it, which I'm very osrry to predict I hope not. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpYYlb3O7Zpd.pgp Description: PGP signature
Re: Comments on pmake diffs for building on Linux
In message: <[EMAIL PROTECTED]> "David O'Brien" <[EMAIL PROTECTED]> writes: : On Wed, Mar 05, 2008 at 01:02:17PM -0700, M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > "David O'Brien" <[EMAIL PROTECTED]> writes: : > : On Tue, Mar 04, 2008 at 10:58:15AM +0100, Rink Springer wrote: : > : > On Tue, Mar 04, 2008 at 10:17:30AM +0200, Giorgos Keramidas wrote: : > : > > Solaris lacks TAILQ_xxx stuff too, so I would prefer something like : > : > > "bsdcompat.h" or similar. : > : > : > : > Seconded - "linux.h" is far too generic. I must say I like the idea : > : > of being able to build *BSD on Linux machines! : > : : > : Why? What are you going to do with it? Presumable install it : > : somewhere, where? : > : : > : Will the differences in the end result of what is built worth the risk, : > : vs. installing VMware player and building FreeBSD on FreeBSD on Linux? : > : > The end result will be the ability to build FreeBSD on a Linux host. : > VMware players aren't an option, and will not be contemplated as an : > acceptable solution. The overhead is too high, especially when : > explaining to people what needs to be done to deploy. : : I think you're wrong about the overhead is too high... - but the proof : will be in the pudding. With installing VMware player and building : FreeBSD on FreeBSD - all the 10,000's of docs explaining to users how : to build will be valid. : : With this cross build these docs will be wrong - folks will be much more : on their own. : : Beyond the docs - I think you underestimate the amount of work getting : all the cross-tools built and installed will be. : : I guess we'll just have to wait and see. Yup. The proof will be in the pudding, as they say. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Comments on pmake diffs for building on Linux
On Wed, Mar 05, 2008 at 01:02:17PM -0700, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > "David O'Brien" <[EMAIL PROTECTED]> writes: > : On Tue, Mar 04, 2008 at 10:58:15AM +0100, Rink Springer wrote: > : > On Tue, Mar 04, 2008 at 10:17:30AM +0200, Giorgos Keramidas wrote: > : > > Solaris lacks TAILQ_xxx stuff too, so I would prefer something like > : > > "bsdcompat.h" or similar. > : > > : > Seconded - "linux.h" is far too generic. I must say I like the idea > : > of being able to build *BSD on Linux machines! > : > : Why? What are you going to do with it? Presumable install it > : somewhere, where? > : > : Will the differences in the end result of what is built worth the risk, > : vs. installing VMware player and building FreeBSD on FreeBSD on Linux? > > The end result will be the ability to build FreeBSD on a Linux host. > VMware players aren't an option, and will not be contemplated as an > acceptable solution. The overhead is too high, especially when > explaining to people what needs to be done to deploy. I think you're wrong about the overhead is too high... - but the proof will be in the pudding. With installing VMware player and building FreeBSD on FreeBSD - all the 10,000's of docs explaining to users how to build will be valid. With this cross build these docs will be wrong - folks will be much more on their own. Beyond the docs - I think you underestimate the amount of work getting all the cross-tools built and installed will be. I guess we'll just have to wait and see. -- -- David ([EMAIL PROTECTED]) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Memory allocation performance
Bruce Evans wrote: Try profiling it one another type of CPU, to get different performance counters but hopefully not very different stalls. If the other CPU doesn't stall at all, put another black mark against P4 and delete your copies of it :-). I have tried to profile the same system with the same load on different hardware: - was Pentium4 2.8 at ASUS MB based on i875G chipset, - now PentiumD 3.0 at Supermicro PDSMi board based on E7230 chipset. The results are completely different. The problem has gone: 0.03 0.04 538550/2154375 ip_forward [11] 0.03 0.04 538562/2154375 em_get_buf [32] 0.07 0.08 1077100/2154375 ng_package_data [26] [15]1.8 0.14 0.15 2154375 uma_zalloc_arg [15] 0.06 0.00 1077151/3232111 generic_bzero [22] 0.03 0.00 538555/538555 mb_ctor_mbuf [60] 0.03 0.00 2154375/4421407 critical_exit [63] 0.02 0.01 538554/2154376 m_freem [42] 0.02 0.01 538563/2154376 mb_free_ext [54] 0.04 0.03 1077100/2154376 ng_free_item [48] [30]0.9 0.08 0.06 2154376 uma_zfree_arg [30] 0.03 0.00 2154376/4421407 critical_exit [63] 0.00 0.01 538563/538563 mb_dtor_pack [82] 0.01 0.00 2154376/4421971 critical_enter [69] So probably it was some hardware related problem. First MB has video integrated to chipset without any dedicated memory, possibly it affected memory performance in some way. On the first system there were such messages on boot: Mar 3 23:01:20 swamp kernel: acpi0: reservation of 0, a (3) failed Mar 3 23:01:20 swamp kernel: acpi0: reservation of 10, 3fdf (3) failed Mar 3 23:01:20 swamp kernel: agp0: controller> on vgapci0 Mar 3 23:01:20 swamp kernel: agp0: detected 892k stolen memory Mar 3 23:01:20 swamp kernel: agp0: aperture size is 128M , can they be related? -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Comments on pmake diffs for building on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Warner Losh wrote: > From: "Daniel O'Connor" <[EMAIL PROTECTED]> > Subject: Re: Comments on pmake diffs for building on Linux > Date: Tue, 4 Mar 2008 17:01:28 +1030 > >> On Tue, 4 Mar 2008, M. Warner Losh wrote: >>> Greetings, >>> >>> here's a set of diffs that will allow FreeBSD's usr.bin/make to build >>> on Linux. I'm sure they are gross, and I don't plan to commit them >>> (at least not all of them), but I thought I'd post them here to see >>> what people think. >>> >>> I think that the extra config.h includes, the errc -> errx patches >>> and the Makefile.dist patches may be good for the tree. The rest may >>> not meet FreeBSD's source tree policies. >>> >>> Comments? I bet a very large portion of those among us who are professional codes have had been forced at some time to port our make, whether it was the original pmake, or the up-to-date version (I did the most up to date I could manage. Getting something like this done would be a greaat thing, it would very seriously help not just ourselves, but all programmers around the world, but i very seriously doubt you'll ever get it done, Thoe folks who thought that making it the most elegant thing on earth without allowing the least consideration towards cross-compatibility, thoes folks are going to raise political hell on every step of the way, bring in every white elephant argument as often as allowed, and most likely force this project into ports, which is a seriously bad place for it to go, because that advertisess that we, thje FreeBSD group, are committed to not giving it any continuing support, and so no one will be able to rely upon it. The politicians amongst us will kill it, which I'm very osrry to predict >> I did this a while ago when porting some of our code to Linux because it >> builds with pmake.. >> >> Your patches are much nicer than mine however :) > > I was in a hurry, since I thought I could do it in a half hour and > that was faster than explaining things... > >> The tailq stuff could be shoved into a linux.h or some such.. So it's >> more obvious what it's for and why it's there. > > I resisted creating a linux.h, but we'll likely need something akin to > it. When I did some Mac OS X experimentation, I had extensions to > legacy to smooth over the rough edges, but it is too early here. > > Warner > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzvygz62J6PPcoOkRApqaAKCGK8FwwRswtegRjR/AQQ+m8Nx4HgCgj1mz 4yEgWsl3Z7wSx1GvTNdk+dA= =I8th -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Comments on pmake diffs for building on Linux
In message: <[EMAIL PROTECTED]> "David O'Brien" <[EMAIL PROTECTED]> writes: : On Tue, Mar 04, 2008 at 10:58:15AM +0100, Rink Springer wrote: : > On Tue, Mar 04, 2008 at 10:17:30AM +0200, Giorgos Keramidas wrote: : > > Solaris lacks TAILQ_xxx stuff too, so I would prefer something like : > > "bsdcompat.h" or similar. : > : > Seconded - "linux.h" is far too generic. I must say I like the idea : > of being able to build *BSD on Linux machines! : : Why? What are you going to do with it? Presumable install it somewhere, : where? : : Will the differences in the end result of what is built worth the risk, : vs. installing VMware player and building FreeBSD on FreeBSD on Linux? The end result will be the ability to build FreeBSD on a Linux host. VMware players aren't an option, and will not be contemplated as an acceptable solution. The overhead is too high, especially when explaining to people what needs to be done to deploy. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpt driver: check raid status
Hello Cristiano, Cristiano Deana [Wed, Mar 05, 2008 at 11:07:31AM +0100]: > I'm using a 7-RELEASE on a Dell PowerEdge 1955, using a mpt driver to > manage a hardware raid1. > Is there any way to check the status of the raid? as far as I know there is currently no support to monitor mpt on FreeBSD, as documentated on http://nico.schottelius.org/documentations/freebsd/freebsd-raid-monitoring/ If you find out more, please send an e-mail to me, so I can update the site. Sincerly Nico -- Think about Free and Open Source Software (FOSS). http://nico.schottelius.org/documentations/foss/the-term-foss/ PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C signature.asc Description: Digital signature
Re: Kernel crash on Asus A7N8X-X
Selon Jeremy Chadwick <[EMAIL PROTECTED]>: > On Tue, Mar 04, 2008 at 11:59:59PM +0100, Frédéric PRACA wrote: > > Hello dear hackers, > > I own a Asus A7N8X-X motherboard (NForce2 chipset) with a Radeon 9600 video > > card. After upgrading from 6.3 to 7.0, I launched xorg which crashed the > kernel. > > After looking in the kernel core dump, I found that the > agp_nvidia_flush_tlb > > function of /usr/src/sys/pci/agp_nvidia.c crashed on the line 377. The loop > > fails from the beginning (when i==0). I commented out the two last loops > and it > > seems to work now but as I didn't understand what is this code for, I'd > like to > > have some explanation about it and want to know if someone got the same > problem. > > I'm in no way familiar with X. > > That said: you're using an ATI Radeon card, yet the kernel crashed in > agp_nvidia.c. nVidia != ATI. Is it possible that you changed video > cards at one point, and you're still using the nVidia AGP driver (loaded > via /boot/loader.conf)? No, in fact, agp_nvidia.c is the driver for the AGP bus of the NForce2 motherboard chipset, not the video card. > dmesg might be useful here. Why not but I can't copy it for the moment. > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel crash on Asus A7N8X-X
On Tue, Mar 04, 2008 at 11:59:59PM +0100, Frédéric PRACA wrote: > Hello dear hackers, > I own a Asus A7N8X-X motherboard (NForce2 chipset) with a Radeon 9600 video > card. After upgrading from 6.3 to 7.0, I launched xorg which crashed the > kernel. > After looking in the kernel core dump, I found that the agp_nvidia_flush_tlb > function of /usr/src/sys/pci/agp_nvidia.c crashed on the line 377. The loop > fails from the beginning (when i==0). I commented out the two last loops and > it > seems to work now but as I didn't understand what is this code for, I'd like > to > have some explanation about it and want to know if someone got the same > problem. I'm in no way familiar with X. That said: you're using an ATI Radeon card, yet the kernel crashed in agp_nvidia.c. nVidia != ATI. Is it possible that you changed video cards at one point, and you're still using the nVidia AGP driver (loaded via /boot/loader.conf)? dmesg might be useful here. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mpt driver: check raid status
On Wed, 5 Mar 2008, Cristiano Deana wrote: Hi, I'm using a 7-RELEASE on a Dell PowerEdge 1955, using a mpt driver to manage a hardware raid1. Is there any way to check the status of the raid? Not really. Now it's running on a single disk (the second one failed and has been removed), and the only thing i can see are: mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 in messages. Thanks in advance mpt0: mpt_cam_event: 0x16 MPI_EVENT_SAS_DISCOVERY most likely started mpt0: mpt_cam_event: 0x12 MPI_EVENT_SAS_PHY_LINK_STATUS mpt0: mpt_cam_event: 0x16 MPI_EVENT_SAS_DISCOVERY most likely done mpt0: mpt_cam_event: 0x15 MPI_EVENT_IR2 that could be LD/PD/... state changed mpt0: mpt_cam_event: 0x21 MPI_EVENT_LOG_ENTRY_ADDED mpt0: mpt_cam_event: 0x15 MPI_EVENT_IR2 mpt0: mpt_cam_event: 0x21 MPI_EVENT_LOG_ENTRY_ADDED mpt0: mpt_cam_event: 0x15 MPI_EVENT_IR2 mpt0: mpt_cam_event: 0x21 MPI_EVENT_LOG_ENTRY_ADDED Giving more details would depend on a subtype which is dependend on the event. What we's really need is someone with the specs to write the code and add the printfs, etc. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel crash on Asus A7N8X-X
Selon Kris Kennaway <[EMAIL PROTECTED]>:
> Fr�d�ric PRACA wrote:
> > Hello dear hackers,
> > I own a Asus A7N8X-X motherboard (NForce2 chipset) with a Radeon 9600 video
> > card. After upgrading from 6.3 to 7.0, I launched xorg which crashed the
> kernel.
> > After looking in the kernel core dump, I found that the
> agp_nvidia_flush_tlb
> > function of /usr/src/sys/pci/agp_nvidia.c crashed on the line 377. The loop
> > fails from the beginning (when i==0). I commented out the two last loops
> and it
> > seems to work now but as I didn't understand what is this code for, I'd
> like to
> > have some explanation about it and want to know if someone got the same
> problem.
>
> Usually it's a good idea to show the data that led to your conclusions
> (backtraces, etc), not just your conclusions. Sometimes there is more
> going on than is immediately apparent.
For sure, sorry.
Here's what I got from kgdb :
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
There is no member named pathname.
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc05b49ac in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc05b4b74 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc06f9858 in vm_fault (map=0xc1054000, vaddr=3570491392,
fault_type=Variable "fault_type" is not available.
)
at /usr/src/sys/vm/vm_fault.c:275
#4 0xc0765be5 in trap_pfault (frame=0xd61f1a48, usermode=0, eva=3570491392)
at /usr/src/sys/i386/i386/trap.c:801
#5 0xc0766502 in trap (frame=0xd61f1a48) at /usr/src/sys/i386/i386/trap.c:490
#6 0xc07545bb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc0776ed7 in agp_nvidia_flush_tlb (dev=0xc2a3b100, offset=-1029891720)
at /usr/src/sys/pci/agp_nvidia.c:377
#8 0xc06bb9dd in agp_generic_bind_memory (dev=0xc2a3b100, mem=0xc2fe7cc0,
offset=0) at agp_if.h:76
#9 0xc06bb001 in agp_bind_memory (dev=0xc2a3b100, handle=0xc2fe7cc0,
offset=0) at agp_if.h:128
#10 0xc04bd1bf in drm_agp_bind_memory (handle=0xc2fe7cc0, start=0)
at /usr/src/sys/dev/drm/drm_agpsupport.c:456
#11 0xc04bd4dd in drm_agp_bind (dev=0xc2aad000, request=0xd61f1b68)
at /usr/src/sys/dev/drm/drm_agpsupport.c:331
#12 0xc04bd591 in drm_agp_bind_ioctl (kdev=0xc2ac3400, cmd=2148033590,
data=0xc2c309d0 "�|��", flags=67, p=0xc2ed7a50, filp=0x17497)
at /usr/src/sys/dev/drm/drm_agpsupport.c:348
#13 0xc04c25e8 in drm_ioctl (kdev=0xc2ac3400, cmd=2148033590,
data=0xc2c309d0 "�|��", flags=67, p=0xc2ed7a50)
---Type to continue, or q to quit---
at /usr/src/sys/dev/drm/drm_drv.c:911
#14 0xc0585ad6 in giant_ioctl (dev=0xc2ac3400, cmd=2148033590,
data=0xc2c309d0 "�|��", fflag=67, td=0xc2ed7a50)
at /usr/src/sys/kern/kern_conf.c:349
#15 0xc0552517 in devfs_ioctl_f (fp=0xc2c3fd38, com=2148033590,
data=0xc2c309d0, cred=0xc4e62400, td=0xc2ed7a50)
at /usr/src/sys/fs/devfs/devfs_vnops.c:494
#16 0xc05e9b43 in kern_ioctl (td=0xc2ed7a50, fd=8, com=2148033590,
data=0xc2c309d0 "�|��") at file.h:266
#17 0xc05e9ca4 in ioctl (td=0xc2ed7a50, uap=0xd61f1cfc)
at /usr/src/sys/kern/sys_generic.c:570
#18 0xc0765f0a in syscall (frame=0xd61f1d38)
at /usr/src/sys/i386/i386/trap.c:1035
#19 0xc0754620 in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:196
#20 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 7
#7 0xc0776ed7 in agp_nvidia_flush_tlb (dev=0xc2a3b100, offset=-1029891720)
at /usr/src/sys/pci/agp_nvidia.c:377
warning: Source file is more recent than executable.
377 temp = ag_virtual[i * PAGE_SIZE / sizeof(u_int32_t)];
(kgdb) list
372
373 ag_virtual = (volatile u_int32_t *)sc->gatt->ag_virtual;
374
375 /* Flush TLB entries. */
376 /*for(i = 0; i < 32 + 1; i++)
377 temp = ag_virtual[i * PAGE_SIZE / sizeof(u_int32_t)];
378 for(i = 0; i < 32 + 1; i++)
379 temp = ag_virtual[i * PAGE_SIZE / sizeof(u_int32_t)];
380 */
381 return (0);
(kgdb) print i
$1 = 0
(kgdb) print *ag_virtual
$2 = 299405313
(kgdb) print ag_virtual
$3 = (volatile u_int32_t *) 0xd4d05000
(kgdb) print *sc
$4 = {agp = {as_aperture = 0xc2a34dc0, as_aperture_rid = 16,
as_maxmem = 461373440, as_allocated = 8388608,
as_state = AGP_ACQUIRE_KERNEL, as_memory = {tqh_first = 0xc2fe7cc0,
tqh_last = 0xc2fe7cc0}, as_nextid = 2, as_isopen = 0,
as_devnode = 0xc2a3c300, as_lock = {lock_object = {
lo_name = 0xc07d15d1 "agp lock", lo_type = 0xc07d15d1 "
mpt driver: check raid status
Hi, I'm using a 7-RELEASE on a Dell PowerEdge 1955, using a mpt driver to manage a hardware raid1. Is there any way to check the status of the raid? Now it's running on a single disk (the second one failed and has been removed), and the only thing i can see are: mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 mpt0: mpt_cam_event: 0x15 mpt0: mpt_cam_event: 0x21 in messages. Thanks in advance -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel crash on Asus A7N8X-X
Frédéric PRACA wrote: Hello dear hackers, I own a Asus A7N8X-X motherboard (NForce2 chipset) with a Radeon 9600 video card. After upgrading from 6.3 to 7.0, I launched xorg which crashed the kernel. After looking in the kernel core dump, I found that the agp_nvidia_flush_tlb function of /usr/src/sys/pci/agp_nvidia.c crashed on the line 377. The loop fails from the beginning (when i==0). I commented out the two last loops and it seems to work now but as I didn't understand what is this code for, I'd like to have some explanation about it and want to know if someone got the same problem. Usually it's a good idea to show the data that led to your conclusions (backtraces, etc), not just your conclusions. Sometimes there is more going on than is immediately apparent. Krs ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
