man ugen error
According to ugen man page, ugen can be compiled into the kernel with device ugen in config file. I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 to RC2, but the kernel build stopped quickly with the message that ugen was not valid. After removing that line from kernel config, make kernel was successful. I didn't find device ugen anywhere in the conf/NOTES or conf/GENERIC files. I hope this man page error can be fixed in time for FreeBSD 9.0-RELEASE. Tom ___ 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
[SOLVED]: HW defect (was: Re: [amd64] Reproducible cold boot failure (reboot succeeds) in -CURRENT)
Am 17.11.2011 17:33, schrieb John Baldwin: On Thursday, November 17, 2011 3:59:43 am Stefan Esser wrote: Am 16.11.2011 17:16, schrieb John Baldwin: [...] That isn't unusual. Those are the addresses of the metadata provided by the loader, not the base address of the kernel or zfs.ko object themselves. The unexpected relocation type is interesting however. That value in hex is 0x40b. 0xb is the R_X86_64_32S relocation type which is normal for the kernel. I think you just have a single-bit memory error due to a failing DIMM. Thanks for the information about the load address semantics. The other unexpected relocation type I observed was 268435457 == 0x1001, which also hints at a single bit error. But today the system failed with a different error: ath0: ... ioapic0: routing interrupt 18 to ... panic: vm_page_insert: page already inserted This could of course also be caused by a single bit error ... Yes, very likely. Hmmm, perhaps there is a problem with components at room temperature and the system is still significantly warmer after 3 hours? Yes, I strongly suspect it is a thermal effect that the RAM works once it is warmed up. If you have data you care about on the machine, I would just go ahead and replace the RAM now before waiting for the RAM's failure to become worse. Thanks a lot, John! I should have checked the hardware before, but since the system was perfectly stable, once it had been up and running, I had been suspecting an initialization bug instead of defective RAM. In fact, one of the 4GB DIMMs in the system returns bogus data (0x1000 or 0x0400 instead of 0) for some 40 to 50 seconds after power-on. Once warmed up, memtest86+ runs for days without a single extra data error (I wanted to have an estimate for the defect having led to damaged data in disk files). When I was still doing hardware work, I always had a freezer aerosol on my desk, which allowed me to quickly cool down a DUT by a few tens of degrees, but without such a tool I had to wait for the components to cool down over night between test. Best regards, STefan ___ 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
[patch] turning devctl into a multiple openable device
Hi all, With the help of cognet, I wrote a patch to turn devctl into a multiple openable device, that mean that it will allow to open /dev/devctl in multiple programs, for example hald and everythings that want to receive notification from the device won't need to depend on haveing devd running. here is the patch: http://people.freebsd.org/~bapt/devctl_multi_open.diff regards, bapt pgp7epJH8F37O.pgp Description: PGP signature
if_bce tx / rx tick limits
Hi, i wonder about the bce driver's tx / rx tick limits (ticks and ticks_int are limited to 100; otherwise default value (80) gets used) (if_bce.c line 921 / 933 .. ) On DragonFly BSD the values can be set much higher (such as 1000 ..) which would be great in a high-traffic setup. (On linux there's no limit too as far as i remember) Is there any reason why its limited down to 100? Thanks Florian P.S. I'm sorry if this was the wrong mailing list for it; i don't know whats the right list for this (probably net or driver ?) ___ 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: if_clone.c allows creating multiple interfaces with the same name
On Tuesday, November 29, 2011 9:28:42 am Gleb Smirnoff wrote:
Daan,
On Tue, Nov 29, 2011 at 01:07:13AM +0100, Daan Vreeken wrote:
D Thanks for the looking into this and for your quick commit. I like your
twist
D on the patch with the move from the unit bitmap to allocating unit numbers
D with alloc_unr(9).
D
D I do have two comments on the new code though.
D Before, in the !wildcard case, ifc_alloc_unit() would return ENOSPC when
the
D user requested a unit number larger than ifc-ifc_maxunit. Now the function
D returns EEXIST in that case because alloc_unr_specific() returns -1 both
D when a number is already allocated and when the number exceeds it's limits.
D This leads to the somewhat confusing:
D
D # ifconfig bridge123456 create
D ifconfig: SIOCIFCREATE2: File exists
D
D Apart from that I'm a bit worried about the /* XXXGL: yep, it's a unit
leak
D */ part of your change. Once a unit number is leaked, there currently
seems
D to be no way to ever get it back. In a worst case scenario, where the
names of
D multiple interfaces in a row collides with the numbers alloc_unr()
returns, an
D entire row of unit numbers could be leaked during the creation of a single
D cloned interface.
D We have a product where cloned interfaces come and go very frequently. I'd
D hate to run out of unit numbers after 'just a few' years of uptime ;-)
D
D I've created a new patch on top of your change that fixes both of these
D problems. Could you have a look at the attached diff?
Thanks, I will work on applying it.
D Considering the second part, that adds locking. Unfortunately, right now
we
D have numerous races in the network configuration ocde. Many
SIOCSsomething
D ioctls can race with each other producing unpredictable results and
kernel
D panics. So, running two ifconfig(8) in parallel is a bad idea today. :(
D Your patch with IFNET_NAMING_LOCK() just plumbs one race case: a race
D between two SIOCSIFNAME ioctls. And it doesn't plumb a race between
D SIOCSIFNAME vs SIOCIFCREATE, because IFNET_NAMING_LOCK() is dropped after
D unit allocation, but prior to interface attachement to global interface
D list.
D
D Are you sure? With the patch in the PR, the relevant code in
D ifc_simple_create() would become :
D
D...
DIFNET_NAMING_LOCK();
Derr = ifc_alloc_unit(ifc, unit);
Dif (err != 0) {
DIFNET_NAMING_UNLOCK();
Dreturn (err);
D}
D
Derr = ifcs-ifcs_create(ifc, unit, params);
DIFNET_NAMING_UNLOCK();
Dif (err != 0) {
Difc_free_unit(ifc, unit);
Dreturn (err);
D}
D...
D
D The lock is acquired before the call to ifc_alloc_unit().
D In the non-error case (e.g. when creating an if_bridge interface) the call
D ends up calling bridge_clone_create(), which calls ether_ifattach(), which
D calls if_attach() - if_attach_internal() where the ifp is added to the
ifnet
D list.
D Only when that's done, the lock is dropped.
D
D Am I overlooking something obvious here?
The code above isn't correct since it holds mutex when calling
ifcs-ifcs_create().
These methods may (they actually do) call malloc() with M_WAITOK.
In general FreeBSD uses M_WAITOK on the configuration code paths, like
any SIOCSsomething ioctl. So to do correct protection, you first need to
allocate every kind of memory needed, then lock mutex, then run through
configuration
sequence, then release mutex and in case of error free all allocated memory.
Sounds easy, but isn't in practice, especially when several network modules
are involved.
So I'm still thinking about...
D From my point of view, we need a generic approach to ioctl() vs ioctl()
D races, may be some global serializer of all re-configuration requests of
D interfaces and addresses.
... but several developers have noted that this approach may have some hidden
problems. When experimenting with new CARP, I have tried it on the
carp_ioctl()
without any problems. The idea is simple:
static int serializer = 0;
static struct mtx serializer_mtx;
MTX_SYSINIT(sermtx, serializer_mtx, ioctl serializer mutex, MTX_DEF);
int
foo_ioctl()
{
mtx_lock(serializer_mtx);
if (serializer != 0)
msleep(serializer, serializer_mtx, 0, ioctl, 0);
serializer = 1;
mtx_unlock(serializer_mtx);
... any code here, uncluding calls to different lower layers...
mtx_lock(serializer_mtx);
serializer = 0;
wakeup(serializer);
mtx_unlock(serializer_mtx);
return (error);
}
I have tried this for carp_ioctl() and it worked fine. You can try it for
entire ifioctl() and all its descendants, but be aware of hidden problems :)
Hmm, is this much different in effect than:
static struct sx serializer_sx;
SX_SYSINIT(...);
int
foo_ioctl()
{
sx_xlock(serializer_sx);
... any code here
Re: [patch] turning devctl into a multiple openable device
On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: Hi all, With the help of cognet, I wrote a patch to turn devctl into a multiple openable device, that mean that it will allow to open /dev/devctl in multiple programs, for example hald and everythings that want to receive notification from the device won't need to depend on haveing devd running. here is the patch: http://people.freebsd.org/~bapt/devctl_multi_open.diff Shouldn't devctl_queue_data_f() use the requested malloc() flags instead of hardcoding M_NOWAIT? Also, I know that it was an intentional design decisison by Warner to have the multiplexing of devctl data done in userland via devd rather than in the kernel. (I think he envisioned devd providing a UNIX domain socket or some such for other daemons to use to listen to events.) Have you asked him about this change? -- John Baldwin ___ 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: [patch] turning devctl into a multiple openable device
On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: Hi all, With the help of cognet, I wrote a patch to turn devctl into a multiple openable device, that mean that it will allow to open /dev/devctl in multiple programs, for example hald and everythings that want to receive notification from the device won't need to depend on haveing devd running. here is the patch: http://people.freebsd.org/~bapt/devctl_multi_open.diff Shouldn't devctl_queue_data_f() use the requested malloc() flags instead of hardcoding M_NOWAIT? you are right, I'll fix that. Also, I know that it was an intentional design decisison by Warner to have the multiplexing of devctl data done in userland via devd rather than in the kernel. (I think he envisioned devd providing a UNIX domain socket or some such for other daemons to use to listen to events.) Have you asked him about this change? I haven't discussed this with him, I just CC him now to have his opinion. In fact for somecase I find useful to have useland application able to get notification from device without having devd running at all plus the devctl(4) manpage says: This design allows only one reader for /dev/devctl. This is not desirable in the long run, but will get a lot of hair out of this implementation. Maybe we should make this device a clonable device. that's why I didn't first spoke to Warner about this, which has been a mistake sorry about that. regards, Bapt pgpeWnhzKvcso.pgp Description: PGP signature
Re: [patch] turning devctl into a multiple openable device
On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: Hi all, With the help of cognet, I wrote a patch to turn devctl into a multiple openable device, that mean that it will allow to open /dev/devctl in multiple programs, for example hald and everythings that want to receive notification from the device won't need to depend on haveing devd running. here is the patch: http://people.freebsd.org/~bapt/devctl_multi_open.diff Shouldn't devctl_queue_data_f() use the requested malloc() flags instead of hardcoding M_NOWAIT? This is an obvious fallback of holding mutex around the call to per_devctl_queue_data_f(), which caused the author a trouble to use M_WAITOK. Having n readers causes the patch to queue each message n times, that looks like a waste. I wonder why the waiting_threads stuff is needed at all. The cv could be woken up unconditionally everytime. What is the reason for the cv_wait call in cdevpriv data destructor ? You cannot have a thread doing e.g. read on the file descriptor while destructor is run. Also, I know that it was an intentional design decisison by Warner to have the multiplexing of devctl data done in userland via devd rather than in the kernel. (I think he envisioned devd providing a UNIX domain socket or some such for other daemons to use to listen to events.) Have you asked him about this change? And I fully agree that doing multiplexing in user mode is the right approach. Not least because you could apply some advanced access control and provide filtering for the consumers. pgpL1GaOrgCj6.pgp Description: PGP signature
Re: [patch] turning devctl into a multiple openable device
On Wed, Nov 30, 2011 at 05:46:36PM +0200, Kostik Belousov wrote: On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: Hi all, With the help of cognet, I wrote a patch to turn devctl into a multiple openable device, that mean that it will allow to open /dev/devctl in multiple programs, for example hald and everythings that want to receive notification from the device won't need to depend on haveing devd running. here is the patch: http://people.freebsd.org/~bapt/devctl_multi_open.diff Shouldn't devctl_queue_data_f() use the requested malloc() flags instead of hardcoding M_NOWAIT? This is an obvious fallback of holding mutex around the call to per_devctl_queue_data_f(), which caused the author a trouble to use M_WAITOK. Having n readers causes the patch to queue each message n times, that looks like a waste. I wonder why the waiting_threads stuff is needed at all. The cv could be woken up unconditionally everytime. What is the reason for the cv_wait call in cdevpriv data destructor ? You cannot have a thread doing e.g. read on the file descriptor while destructor is run. Also, I know that it was an intentional design decisison by Warner to have the multiplexing of devctl data done in userland via devd rather than in the kernel. (I think he envisioned devd providing a UNIX domain socket or some such for other daemons to use to listen to events.) Have you asked him about this change? And I fully agree that doing multiplexing in user mode is the right approach. Not least because you could apply some advanced access control and provide filtering for the consumers. I agree that in most cases this is better, but being able to have multiple readers is anyway useful, having the futur libudev or alike not depends on devd running would be great imho. I have boxes that do not have devd and won't have it would be useless but run programs that needs to get notification for some hardware. I would love to remove devd on those boxes (they are boxes where the FS size is limited) regards, Bapt pgpL2XyYlWW0V.pgp Description: PGP signature
Re: WITHOUT_PROFILE=yes by default
On 30/11/2011 01:16, Doug Barton wrote: What does dtrace have to do with profiled libs? system breaks if you try to add dtrace support to a system built with profile support. on the other hand it could be argued that the system currently needs to be rebuilt anyway. Sevan ___ 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: [patch] turning devctl into a multiple openable device
On Wed, Nov 30, 2011 at 04:55:21PM +0100, Olivier Houchard wrote: On Wed, Nov 30, 2011 at 05:46:36PM +0200, Kostik Belousov wrote: On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: Hi all, With the help of cognet, I wrote a patch to turn devctl into a multiple openable device, that mean that it will allow to open /dev/devctl in multiple programs, for example hald and everythings that want to receive notification from the device won't need to depend on haveing devd running. here is the patch: http://people.freebsd.org/~bapt/devctl_multi_open.diff Shouldn't devctl_queue_data_f() use the requested malloc() flags instead of hardcoding M_NOWAIT? This is an obvious fallback of holding mutex around the call to per_devctl_queue_data_f(), which caused the author a trouble to use M_WAITOK. Having n readers causes the patch to queue each message n times, that looks like a waste. Queuing the message only one time would require to somehow keep a state, to know which thread read which message, and figuring out when to free a message can be an headache. Given I don't think they'll be a lot of readers, I'm not sure it's worth the trouble. I wonder why the waiting_threads stuff is needed at all. The cv could be woken up unconditionally everytime. What is the reason for the cv_wait call in cdevpriv data destructor ? You cannot have a thread doing e.g. read on the file descriptor while destructor is run. What will prevent you from having a thread stuck in read(), while an another one close() the fd ? Nothing, but file reference count goes to zero only after the thread stuck in read is unstuck. Cdevpriv destructor is run only when file reference count becomes zero, i.e. there can be no any accessing threads, and new accesses are impossible since file descriptors also own references on the file. pgpc9tuCURiWe.pgp Description: PGP signature
Re: [patch] turning devctl into a multiple openable device
On Wed, Nov 30, 2011 at 05:46:36PM +0200, Kostik Belousov wrote: On Wed, Nov 30, 2011 at 10:05:11AM -0500, John Baldwin wrote: On Wednesday, November 30, 2011 7:43:20 am Baptiste Daroussin wrote: Hi all, With the help of cognet, I wrote a patch to turn devctl into a multiple openable device, that mean that it will allow to open /dev/devctl in multiple programs, for example hald and everythings that want to receive notification from the device won't need to depend on haveing devd running. here is the patch: http://people.freebsd.org/~bapt/devctl_multi_open.diff Shouldn't devctl_queue_data_f() use the requested malloc() flags instead of hardcoding M_NOWAIT? This is an obvious fallback of holding mutex around the call to per_devctl_queue_data_f(), which caused the author a trouble to use M_WAITOK. Having n readers causes the patch to queue each message n times, that looks like a waste. Queuing the message only one time would require to somehow keep a state, to know which thread read which message, and figuring out when to free a message can be an headache. Given I don't think they'll be a lot of readers, I'm not sure it's worth the trouble. I wonder why the waiting_threads stuff is needed at all. The cv could be woken up unconditionally everytime. What is the reason for the cv_wait call in cdevpriv data destructor ? You cannot have a thread doing e.g. read on the file descriptor while destructor is run. What will prevent you from having a thread stuck in read(), while an another one close() the fd ? Regards, Olivier ___ 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: man ugen error
On Wednesday 30 November 2011 11:24:39 Thomas Mueller wrote: According to ugen man page, ugen can be compiled into the kernel with device ugen in config file. I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 to RC2, but the kernel build stopped quickly with the message that ugen was not valid. After removing that line from kernel config, make kernel was successful. I didn't find device ugen anywhere in the conf/NOTES or conf/GENERIC files. I hope this man page error can be fixed in time for FreeBSD 9.0-RELEASE. FYI: device ugen is now part of device usb Could you send me a manpage diff? --HPS ___ 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: [patch] turning devctl into a multiple openable device
On Wednesday 30 November 2011 13:43:20 Baptiste Daroussin wrote: Hi all, With the help of cognet, I wrote a patch to turn devctl into a multiple openable device, that mean that it will allow to open /dev/devctl in multiple programs, for example hald and everythings that want to receive notification from the device won't need to depend on haveing devd running. here is the patch: http://people.freebsd.org/~bapt/devctl_multi_open.diff regards, bapt Comment: Is the track-close flag set for the devfs sw? --HPS ___ 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: [patch] turning devctl into a multiple openable device
On Wed, Nov 30, 2011 at 06:04:50PM +0200, Kostik Belousov wrote: I wonder why the waiting_threads stuff is needed at all. The cv could be woken up unconditionally everytime. What is the reason for the cv_wait call in cdevpriv data destructor ? You cannot have a thread doing e.g. read on the file descriptor while destructor is run. What will prevent you from having a thread stuck in read(), while an another one close() the fd ? Nothing, but file reference count goes to zero only after the thread stuck in read is unstuck. Cdevpriv destructor is run only when file reference count becomes zero, i.e. there can be no any accessing threads, and new accesses are impossible since file descriptors also own references on the file. Right, I was a bit confused, this part can be removed. Regards, Olivier ___ 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: if_bce tx / rx tick limits
On Wed, Nov 30, 2011 at 03:22:37PM +0100, Florian Wilkemeyer wrote: Hi, i wonder about the bce driver's tx / rx tick limits (ticks and ticks_int are limited to 100; otherwise default value (80) gets used) (if_bce.c line 921 / 933 .. ) I think this highly depends on firmware of controller. David may be able to answer(CCed). On DragonFly BSD the values can be set much higher (such as 1000 ..) which would be great in a high-traffic setup. (On linux there's no limit too as far as i remember) No, the value should be represented with 10bits so having no limit looks like a bug in Linux. Is there any reason why its limited down to 100? Thanks Florian P.S. I'm sorry if this was the wrong mailing list for it; i don't know whats the right list for this (probably net or driver ?) ___ 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
[CFT] pkgng alpha2
Hi all, We are releasing pkgng (the next pkg_install) alpha2 to the world and we want you to test it! There is no good method to test it: use it as you would in the real world. Of course, you are encouraged to backup your data or test it in some kind of virtualized environment. After using it for some time, you will certainly find bugs. You can report them on the issues tracker [1]. If you find missing features, that is things you can't do with pkgng but can with pkg_install, you can also report them. New features are not the expected outcome of this call, as we want to release a final version ASAP. FYI, an alpha3 should follow shortly to fix issues in alpha3 and test additional features. After that, there will be a feature freeze with beta1. Getting started: You can download or git clone the source code of pkgng on the github page [2]. Then, a boring `make' followed by `make install' will do it. If you have some packages installed by pkg_add, you can convert the old database to the pkgng database with the 'pkg2ng' shell script in the ports/ folder. You can also add packages from the ports tree (with bsd.pkgng.mk) or with a pkgng repository. All is documented in the README and manpages. If you are a newcomer to pkgng, this doc reading step is also valuable to us. Indeed, if you fight to get the right infos, or if some things feel counter intuitive, we should improve it! Which brings me to the topic of contributing to pkgng. The best thing you can do is to write down the documentation you would have loved to read while testing pkgng! And of course, if you have a patch with your bug report, it is much appreciated. If you read this entire mail and wonder what is this pkgng thing, you can read the wiki page [3], bapt's presentation from BSDCan [4], EuroBSDCon [5] [6] and browse the source code. Regards, Julien, on behalf of the pkgng team. And remember, we _do_ want to hear back from you! Please also note that it is still alpha code and it can kill kitten and puppies. You are warned ;-) [1] : https://github.com/pkgng/pkgng/issues [2] : https://github.com/pkgng/pkgng [3] : http://wiki.freebsd.org/pkgng [4] : http://people.freebsd.org/~bapt/pkgng-bsdcan2011.pdf [5] : http://wiki.freebsd.org/201110DevSummit/Ports?action=AttachFiledo=gettarget=pkgng-devsummit.pdf [6] : http://wiki.freebsd.org/201110DevSummit?action=AttachFiledo=gettarget=pkgng-devsummit-track.pdf ___ 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: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. -- 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: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. Jung-uk Kim ___ 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
Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C)
I have a Shuttle based intel box that appears to have some pretty bad ACPI implementation. Is there a good way to quiesce this spam? The console fills up with repeated warnings that never cease. FreeBSD testbox 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228164S: Wed Nov 30 16:19:16 PST 2011 sbruno@testbox:/tmp/foo/bsd/head/sys/GENERIC_NO_1394 amd64 [sbruno@testbox ~]$ sysctl -a |grep thermal Giant,ACPI thermal zone hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: -273.2C hw.acpi.thermal.tz0.active: -2 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 50.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 60.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 60 ... dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THRM dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 Sean ___ 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: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On Wednesday 30 November 2011 06:07 pm, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebs d-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. BTW, I needed another patch to build virtual-ose-kmod on head: http://people.freebsd.org/~jkim/patch-src-VBox-HostDrivers-Support-freebsd-SUPDrv-freebsd.c FYI... Jung-uk Kim ___ 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: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
on 01/12/2011 01:27 Jung-uk Kim said the following: On Wednesday 30 November 2011 06:07 pm, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebs d-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. BTW, I needed another patch to build virtual-ose-kmod on head: http://people.freebsd.org/~jkim/patch-src-VBox-HostDrivers-Support-freebsd-SUPDrv-freebsd.c FYI... Yep, me too, obviously :-) Thank you for the complete vm_page_alloc_contig patch! -- 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: Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C)
on 01/12/2011 01:22 Sean Bruno said the following: I have a Shuttle based intel box that appears to have some pretty bad ACPI implementation. Is there a good way to quiesce this spam? Ask on acpi@ list. Kidding :-) or not. Try hw.acpi.thermal.polling_rate=0. The console fills up with repeated warnings that never cease. FreeBSD testbox 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228164S: Wed Nov 30 16:19:16 PST 2011 sbruno@testbox:/tmp/foo/bsd/head/sys/GENERIC_NO_1394 amd64 [sbruno@testbox ~]$ sysctl -a |grep thermal Giant,ACPI thermal zone hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: -273.2C hw.acpi.thermal.tz0.active: -2 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 50.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 60.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 60 ... dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THRM dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 -- 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: Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C)
On Wednesday 30 November 2011 06:40 pm, Andriy Gapon wrote: on 01/12/2011 01:22 Sean Bruno said the following: I have a Shuttle based intel box that appears to have some pretty bad ACPI implementation. Is there a good way to quiesce this spam? Ask on acpi@ list. Kidding :-) or not. Try hw.acpi.thermal.polling_rate=0. Adding the following line in /boot/loader.conf will disable acpi_thermal(4) completely: debug.acpi.disabled=thermal Jung-uk Kim The console fills up with repeated warnings that never cease. FreeBSD testbox 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228164S: Wed Nov 30 16:19:16 PST 2011 sbruno@testbox:/tmp/foo/bsd/head/sys/GENERIC_NO_1394 amd64 [sbruno@testbox ~]$ sysctl -a |grep thermal Giant,ACPI thermal zone hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: -273.2C hw.acpi.thermal.tz0.active: -2 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 50.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 60.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 60 ... dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THRM dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 ___ 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: WITHOUT_PROFILE=yes by default
On 30/11/2011 16:03, Sevan / Venture37 wrote: system breaks if you try to add dtrace support to a system built with profile support. sorry, I meant *without* profile support. Sevan ___ 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: Remove debug echo
On Tue Nov 29 11, Warner Losh wrote:
kill it.
Warner
On Nov 29, 2011, at 2:07 PM, John Baldwin wrote:
Any objections to this? It removes a weird line during 'make -s
buildworld'
output and I think it was debugging accidentally left in in 213077 by
Warner:
Index: newvers.sh
===
--- newvers.sh (revision 228074)
+++ newvers.sh (working copy)
@@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do
done
if [ -n $svnversion ] ; then
- echo $svnversion
svn=`cd ${SYSDIR} $svnversion`
case $svn in
[0-9]*) svn= r${svn} ;;
also...
when running buildkernel via 'make -s', do we really need all those module
printfs? i see messages for cleandir, obj, depend and all. i think for
'make -s', that's pure overkill!
for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 and
you'll get 2680 lines of output. not really *silent*, is it? ;)
cheers.
alex
--
John Baldwin
___
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: Remove debug echo
On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best arun...@freebsd.org wrote:
On Tue Nov 29 11, Warner Losh wrote:
kill it.
Warner
On Nov 29, 2011, at 2:07 PM, John Baldwin wrote:
Any objections to this? It removes a weird line during 'make -s
buildworld'
output and I think it was debugging accidentally left in in 213077 by
Warner:
Index: newvers.sh
===
--- newvers.sh (revision 228074)
+++ newvers.sh (working copy)
@@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do
done
if [ -n $svnversion ] ; then
- echo $svnversion
svn=`cd ${SYSDIR} $svnversion`
case $svn in
[0-9]*) svn= r${svn} ;;
also...
when running buildkernel via 'make -s', do we really need all those module
printfs? i see messages for cleandir, obj, depend and all. i think for
'make -s', that's pure overkill!
for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 and
you'll get 2680 lines of output. not really *silent*, is it? ;)
pmake sucks as far as diagnostic output is concerned when compared
with gmake. I'd rather not have to fish through with -j1 (if I'm lucky
and it's not a race) to determine what directory created the Error
Code output. With the printouts discussed here, at least you have a
chance at determining what the issue was.
Maybe it's just me, but I like noisy builds -- otherwise the
amount of time I have to spend root-causing the issue becomes
expensive.
Thanks,
-Garrett
___
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: Remove debug echo
On Wed Nov 30 11, Garrett Cooper wrote:
On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best arun...@freebsd.org wrote:
On Tue Nov 29 11, Warner Losh wrote:
kill it.
Warner
On Nov 29, 2011, at 2:07 PM, John Baldwin wrote:
Any objections to this? It removes a weird line during 'make -s
buildworld'
output and I think it was debugging accidentally left in in 213077 by
Warner:
Index: newvers.sh
===
--- newvers.sh (revision 228074)
+++ newvers.sh (working copy)
@@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do
done
if [ -n $svnversion ] ; then
- echo $svnversion
svn=`cd ${SYSDIR} $svnversion`
case $svn in
[0-9]*) svn= r${svn} ;;
also...
when running buildkernel via 'make -s', do we really need all those module
printfs? i see messages for cleandir, obj, depend and all. i think
for
'make -s', that's pure overkill!
for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4 and
you'll get 2680 lines of output. not really *silent*, is it? ;)
pmake sucks as far as diagnostic output is concerned when compared
with gmake. I'd rather not have to fish through with -j1 (if I'm lucky
and it's not a race) to determine what directory created the Error
Code output. With the printouts discussed here, at least you have a
chance at determining what the issue was.
Maybe it's just me, but I like noisy builds -- otherwise the
amount of time I have to spend root-causing the issue becomes
expensive.
ehmmm...a noisy silent flag? i totally agree, if we're talking about 'make' in
its default mode, but what's the point of a silent flag, if it produces 2500
lines of output? nobody uses the -s flag for diagnostics. its purpose is to
build a kernel without producing a lot of output and also not fiddling with
stdout/stderr to achieve that goal.
cheers.
alex
Thanks,
-Garrett
___
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: Remove debug echo
On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best arun...@freebsd.org wrote:
On Wed Nov 30 11, Garrett Cooper wrote:
On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best arun...@freebsd.org wrote:
On Tue Nov 29 11, Warner Losh wrote:
kill it.
Warner
On Nov 29, 2011, at 2:07 PM, John Baldwin wrote:
Any objections to this? It removes a weird line during 'make -s
buildworld'
output and I think it was debugging accidentally left in in 213077 by
Warner:
Index: newvers.sh
===
--- newvers.sh (revision 228074)
+++ newvers.sh (working copy)
@@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do
done
if [ -n $svnversion ] ; then
- echo $svnversion
svn=`cd ${SYSDIR} $svnversion`
case $svn in
[0-9]*) svn= r${svn} ;;
also...
when running buildkernel via 'make -s', do we really need all those module
printfs? i see messages for cleandir, obj, depend and all. i think
for
'make -s', that's pure overkill!
for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4
and
you'll get 2680 lines of output. not really *silent*, is it? ;)
pmake sucks as far as diagnostic output is concerned when compared
with gmake. I'd rather not have to fish through with -j1 (if I'm lucky
and it's not a race) to determine what directory created the Error
Code output. With the printouts discussed here, at least you have a
chance at determining what the issue was.
Maybe it's just me, but I like noisy builds -- otherwise the
amount of time I have to spend root-causing the issue becomes
expensive.
ehmmm...a noisy silent flag? i totally agree, if we're talking about 'make' in
its default mode, but what's the point of a silent flag, if it produces 2500
lines of output? nobody uses the -s flag for diagnostics. its purpose is to
build a kernel without producing a lot of output and also not fiddling with
stdout/stderr to achieve that goal.
What I really want is this:
$ cat Makefile
all: foo bar baz yadda
foo bar yadda:
baz:
false
$ gmake
false
gmake: *** [baz] Error 1
$ make all
false
*** Error code 1
Stop in /tmp.
Otherwise diagnosing issues becomes a PITA with -j 1 (with pmake I
have to start using some serious grep'ing, and if I'm lucky I can find
the source of error). If I get a few spare cycles I might just
implement it and post a patch somewhere (the entering and leaving
directory feature of gmake is really nice too, but it's less
important.. unless you have the same target in multiple directories)..
Thanks,
-Garrett
___
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: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On Tue, 29 Nov 2011 19:22:39 +0300 Sergey Kandaurov pluk...@gmail.com wrote: On 29 November 2011 20:16, Maxim Khitrov m...@mxcrypt.com wrote: On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov pluk...@gmail.com wrote: On 26 November 2011 11:44, Milan Obuch freebsd-curr...@dino.sk wrote: Hi, I am playing a bit with 9.0-PRERELEASE compiling it from source updated via csup. In both example files there is line specifying what to csup *default release=cvs tag=RELENG_8 which is incorrect, I think. It is convenient for me to issue just csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile to update full sources without need to create any cvsup config file, however in system installed from 9.0 snapshot (maybe two weeks old) this file points to version 8 files, so I need to correct it for 9.0-PRERELEASE to not accidentally download older version sources. The same is also true after upgrade from source - make installworld install example files pointing to older version... Is it something I do not know about or is it an oversight? I think this line should already be changed to new tag... *default release=cvs tag=RELENG_9 Hi. Fixed. Thanks for your report. Now cvs tag points to RELENG_9 in 9.x sources. Should standard-supfile also be updated to point to RELENG_9_0? I'm using csup with tag=RELENG_9_0 and standard-supfile still points to HEAD. Yep, sure. I just sent a request to the Release Engineering Team. It works for me now as expected, thanks. Anyway, there is a question what the difference between stable-supfile and standard-supfile should be. I looked in my local csupped sources, they are the same in 6-STABLE (OK, some history here), 7-STABLE, 8-STABLE and 9-STABLE. Are they expected to be used differently? And, second one - what about CURRENT? In stable-supfile I see tag=RELENG_9 which is not quite clear, but just for some pedantry... I use standard-supfile for CURRENT, so this is not an issue for me either. Regards, Milan ___ 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: Remove debug echo
On Wed, Nov 30, 2011 at 5:59 PM, Garrett Cooper yaneg...@gmail.com wrote:
On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best arun...@freebsd.org wrote:
On Wed Nov 30 11, Garrett Cooper wrote:
On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best arun...@freebsd.org wrote:
On Tue Nov 29 11, Warner Losh wrote:
kill it.
Warner
On Nov 29, 2011, at 2:07 PM, John Baldwin wrote:
Any objections to this? It removes a weird line during 'make -s
buildworld'
output and I think it was debugging accidentally left in in 213077 by
Warner:
Index: newvers.sh
===
--- newvers.sh (revision 228074)
+++ newvers.sh (working copy)
@@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do
done
if [ -n $svnversion ] ; then
- echo $svnversion
svn=`cd ${SYSDIR} $svnversion`
case $svn in
[0-9]*) svn= r${svn} ;;
also...
when running buildkernel via 'make -s', do we really need all those module
printfs? i see messages for cleandir, obj, depend and all. i
think for
'make -s', that's pure overkill!
for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times 4
and
you'll get 2680 lines of output. not really *silent*, is it? ;)
pmake sucks as far as diagnostic output is concerned when compared
with gmake. I'd rather not have to fish through with -j1 (if I'm lucky
and it's not a race) to determine what directory created the Error
Code output. With the printouts discussed here, at least you have a
chance at determining what the issue was.
Maybe it's just me, but I like noisy builds -- otherwise the
amount of time I have to spend root-causing the issue becomes
expensive.
ehmmm...a noisy silent flag? i totally agree, if we're talking about 'make'
in
its default mode, but what's the point of a silent flag, if it produces
2500
lines of output? nobody uses the -s flag for diagnostics. its purpose is to
build a kernel without producing a lot of output and also not fiddling with
stdout/stderr to achieve that goal.
What I really want is this:
$ cat Makefile
all: foo bar baz yadda
foo bar yadda:
baz:
false
$ gmake
false
gmake: *** [baz] Error 1
$ make all
false
*** Error code 1
Stop in /tmp.
Otherwise diagnosing issues becomes a PITA with -j 1 (with pmake I
have to start using some serious grep'ing, and if I'm lucky I can find
the source of error). If I get a few spare cycles I might just
implement it and post a patch somewhere (the entering and leaving
directory feature of gmake is really nice too, but it's less
important.. unless you have the same target in multiple directories)..
I've attached a patch that makes make do what I would like it to do;
there are some other items that require cleanup to achieve the `argv0'
prefixing that's available in gmake, but this is good enough for a
meaningful traceback when things fail. Pastebin available here, just
in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv
$ cat ~/Makefile
all:
cd $$HOME/foo; ${MAKE} $@
$ cat ~/foo/Makefile
all: foo bar barf yadda
foo bar yadda:
@true
baz:
@false
barf: baz
$ $PWD/make -j4 -f ~/Makefile all
cd $HOME/foo; /usr/src/usr.bin/make/make all
*** [baz] Error code 1
1 error
*** [all] Error code 2
1 error
$
If someone would please, PLEASE commit this.. I will give you beer, or
wine, or a copy of Skyrim, or a few months subscription to WoW, or
something else of value to you that we could negotiate :)... I'm quite
frankly tired of having to playing guessing games fishing through logs
trying to determine build errors on FreeBSD if and when they do occur
with pmake, and I'm sure that a number of developers and build/release
engineers out there are in the same boat as I am.
Thanks,
-Garrett
more-meaningful-make-errors.patch
Description: Binary data
___
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
