Re: a question regarding sys/shm.h
On Wed, 2007-Jan-31 08:30:27 +0100, Pascal Hofstee wrote: In a recent attempt in trying to clean up some compiler warnings in a GNUstep related project i came upon a case where the FreeBSD datatypes seemed to disagree with the Linux ones. Though this in itself is not unusual i do wonder if in this case the Linux definition isn't the more proper one. The definition in question is inside sys/shm.h and involves struct shmid_ds.shm_segsz which seems to be defined as int whereas Linux defines this as size_t. Whilst I agree that the Linux defn is the more sensible one, System V IPC and common sense are not commonly found together. Tradionally the definition was int. It appears that the definition changed from int to size_t in issue 5 of the Open Group base definition but FreeBSD has not caught up with this. I'm not sure what plans there are to change this. You could try putting together a patch to address this and submitting it as a PR (this means addressing all references to shm_segsz in the base system, not just sys/shm.h). -- Peter Jeremy pgp8hjEZLqbWd.pgp Description: PGP signature
Re: a question regarding sys/shm.h
Peter Jeremy wrote: Whilst I agree that the Linux defn is the more sensible one, System V IPC and common sense are not commonly found together. Tradionally the definition was int. It appears that the definition changed from int to size_t in issue 5 of the Open Group base definition but FreeBSD has not caught up with this. I'm not sure what plans there are to change this. You could try putting together a patch to address this and submitting it as a PR (this means addressing all references to shm_segsz in the base system, not just sys/shm.h). First of all, thanks for the quick response. At the very least this sheds some light onto the history and how this situation likely came to pass. I'll see if i can put together a patch during the next week or so that would bring our definitions regarding System V IPC in synch, i'll also try to see if i can find additional occurances of similar discrepancies so these could be fixed in a single run. Any additional sugestions/objections are always greatly appreciated. -- Pascal Hofstee ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a question regarding sys/shm.h
Pascal Hofstee [EMAIL PROTECTED] writes: Any additional sugestions/objections are always greatly appreciated. On 32-bit platforms (i386, powerpc), int is a 32-bit signed integer while size_t is a 32-bit unsigned integer. On 64-bit platforms (amd64, sparc64 etc), int is a 32-bit signed integer while size_t is a 64-bit unsigned integer. In both cases, changing this structure member from int to size_t will break the ABI. This doesn't mean you shouldn't do it, just that it should be done with care. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysctl(3) interface
Daniel Rudy [EMAIL PROTECTED] writes: I've been taking apart and analyzing the sysctl(8) program to gain a better insight into how to use the sysctl(3) interface. [...] It's using an oid of 0 and 2 to get something, then it comes up with 440 and then a sequence of numbers that are incrementing in a peculiar pattern. sysctl(8) uses undocumented interfaces to a) enumerate the nodes in the sysctl tree and b) obtain the name of a node, given its OID. So, my question is, how do I walk the tree to get the PnP info for all the devices in the system? man 3 devinfo DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a question regarding sys/shm.h
On Wed, 31 Jan 2007, Dag-Erling Smørgrav wrote: Pascal Hofstee [EMAIL PROTECTED] writes: Any additional sugestions/objections are always greatly appreciated. On 32-bit platforms (i386, powerpc), int is a 32-bit signed integer while size_t is a 32-bit unsigned integer. On 64-bit platforms (amd64, sparc64 etc), int is a 32-bit signed integer while size_t is a 64-bit unsigned integer. In both cases, changing this structure member from int to size_t will break the ABI. This doesn't mean you shouldn't do it, just that it should be done with care. If we do decide to go ahead with the ABI change, there are a number of other things that should be done simultaneously, such as changing the uid and gid fields to uid_t and gid_t. I would very much like to see the ABI change happen, and the first step (breaking out kernel from user structures) has been done already as part of the MAC work. The next step is to add routines that translate internal/external formats, which isn't hard, but requires a moderate pile of code to do (as well as great care :-). Robert N M Watson Computer Laboratory University of Cambridge___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a question regarding sys/shm.h
Robert Watson [EMAIL PROTECTED] wrote: On Wed, 31 Jan 2007, Dag-Erling Smørgrav wrote: Pascal Hofstee [EMAIL PROTECTED] writes: Any additional sugestions/objections are always greatly appreciated. On 32-bit platforms (i386, powerpc), int is a 32-bit signed integer while size_t is a 32-bit unsigned integer. On 64-bit platforms (amd64, sparc64 etc), int is a 32-bit signed integer while size_t is a 64-bit unsigned integer. In both cases, changing this structure member from int to size_t will break the ABI. This doesn't mean you shouldn't do it, just that it should be done with care. If we do decide to go ahead with the ABI change, there are a number of other things that should be done simultaneously, such as changing the uid and gid fields to uid_t and gid_t. struct tm's members could be changed as well. Quoting a response I got from Juliusz Chroboczek (the author of Polipo) after reporting a compiler warning: |By the way, IEEE 1003.1-2003 says that tv_sec should be a time_t, |hence by making it a long, FreeBSD and NetBSD are violating the POSIX |standard. Could you please file a bug report with them? I didn't find any claims about FreeBSD being IEEE 1003.1-2003 compliant and therefore didn't consider it a bug, but given that the topic is *_t changes and time_t hasn't come up yet, I'd like to mention it anyway. Fabian signature.asc Description: PGP signature
Re: top delay value
Dr. Markus Waldeck wrote: Oliver Fromme wrote: Well, an unprivileged user can achieve the same effect by typing while :; do :; done. There are a thousand ways to waste CPU time, and there is no way to prevent a user from doing it. It is not the same effect. You describe fork bombing. No. What I write above is not a fork bomb, it's a single process which is wasting CPU in a busy loop. It's exactly equivalent to top(1) with zero delay, except that top produces some output, while a busy loop does nothing useful at all. I could limit the number of process via :maxproc=100: \ in /etc/login.conf Which doesn't help against a busy loop. If you want to make top more secure, type chmod 700 /usr/bin/top. :-) Actually I was serious. Normal users don't really need to run top (which is only contributed third-party software anyway). It doesn't provide any information that you can't get with other regular tools, such as ps(1) which is a native FreeBSD tools. By the way, you can emulate top(1) with run ps(1) in a shell loop like this (sh/zsh/ksh/bash syntax): while :; do clear; ps -a; sleep 1; done Do get zero delay, simply remove the sleep command from the loop ... That's actually _worse_ than top(1) with zero delay, because kernel cycles are wasted for the fork() and exec() calls, not to mention I/O and other syscalls. An empty shell loop (while :; do :; done) doesn't perform any syscalls into the kernel. Bottom line: Disabling zero-delay in top doesn't buy you anything at all. In fact, it might cause your users to invent work-arounds (for example shell loops) that waste even more resources. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783 Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd ... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies.-- C.A.R. Hoare, ACM Turing Award Lecture, 1980 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN controller
Hi Folks, A new version of the driver is up which fixes the firmware issues. Seems the wpi-firmware-kmod port was creating corrupt modules. Things should work much better now. Download at the same place, file: 20070131-wpi-freebsd.tar.gz Cheers, Benjamin Sam Fourman Jr. wrote: I can also confirm that i get the firmware_get: failed to load firmware image wpi_fw on the 20070125 version. I should note that I tried it on a fresh 6.2 RELEASE install. Sam Fourman Jr. On 1/27/07, Gilbert Cao [EMAIL PROTECTED] wrote: On Fri, Jan 26, 2007 at 11:09:51PM +1030, Benjamin Close wrote: Hi Gilbert, Thanks for the custom version. I've integrated the changes into the driver I'm working on. For those wanting to test out the driver which is now fully up to date with all change from NetBSD OpenBSD - and has a few minor improvements over them, grab it from: http://www.clearchain.com/~benjsc/download/ File is: 20070125-wpi-freebsd.tar.gz Full instructions on how to build / install the driver are in the README in the tar file. This should work both under -current and 6.2-Stable now. Info about the driver and what's working/broken can be found at: http://www.clearchain.com/wiki/wpi Cheers, Benjamin I have tried the new 20070125 version. However, I did not manage to make work. At least, it compiles. I have installed, both wpi_fw.ko and the if_wpi.ko, as the README said. wpi_fw.ko lies in /boot/modules and if_wpi.ko in /boot/kernel. When, I kldload if_wpi, here is a small sample of /var/log/messages Jan 27 10:30:39 vaio kernel: wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xcc00-0xcc000fff irq 18 at device 0.0 on pci6 Jan 27 10:30:39 vaio kernel: bus_dmamem_alloc failed to align memory properly. Jan 27 10:30:39 vaio last message repeated 6 times Jan 27 10:30:39 vaio kernel: wpi0: Ethernet address: 00:18:de:5c:cb:9a Jan 27 10:30:39 vaio kernel: wpi0: [GIANT-LOCKED] Jan 27 10:30:39 vaio kernel: wpi0: 11a rates: Jan 27 10:30:39 vaio kernel: wpi0: 11b rates: Jan 27 10:30:40 vaio kernel: firmware_get: failed to load firmware image wpi_fw Jan 27 10:30:40 vaio kernel: wpi0: could not load firmware image 'wpi_fw' Jan 27 10:30:40 vaio kernel: firmware_get: failed to load firmware image wpi_fw Jan 27 10:30:40 vaio kernel: wpi0: could not load firmware image 'wpi_fw' Jan 27 10:32:19 vaio kernel: firmware_get: failed to load firmware image wpi_fw Jan 27 10:32:19 vaio kernel: wpi0: could not load firmware image 'wpi_fw' In kldstat, both modules are loaded. Then, I have kldunload if_wpi (and if_wpi seems to be reload, automatically, I don't know why). Same problem, it seems that wpi_fw could not be load (found ?). As a result, no AP is associated. After a fresh reboot, I have reinstall the custom 20070121 version of mine, and all returns OK. Another strange thing: when kldload if_wpi with 20070121 version, and then kldstat, I don't see wpi_ucode. It seems that wpi_ucode.ko does not need to be loaded, in my case. My wpi_ucode.ko lies in /boot/modules After another fresh reboot, I first moved wpi_ucode.ko to another place. When I kldload if_wpi, I got the following message: Jan 27 09:47:16 vaio kernel: wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xcc00-0xcc000fff irq 18 at device 0.0 on pci6 Jan 27 09:47:16 vaio kernel: bus_dmamem_alloc failed to align memory properly. Jan 27 09:47:16 vaio last message repeated 6 times Jan 27 09:47:16 vaio kernel: wpi0: Ethernet address: 00:18:de:5c:cb:9a Jan 27 09:47:16 vaio kernel: wpi0: [GIANT-LOCKED] Jan 27 09:47:16 vaio kernel: wpi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Jan 27 09:47:16 vaio kernel: wpi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Jan 27 09:47:16 vaio kernel: wpi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps Jan 27 09:47:16 vaio kernel: firmware_get: failed to load firmware image wpi_ucode Jan 27 09:47:16 vaio kernel: wpi0: could not load firmware image 'wpi_ucode' So, it seems that wpi_ucode.ko have to lied in my /boot/modules (the place where I have also put if_wpi 20070121 version), even if it is not loaded. -- (hika) Gilbert Cao http://www.miaouirc.com - MiaouIRC Project 2002-2003 http://www.bsdmon.com - The BSD DMON Power to serve IRC : #miaule at IRCNET Network ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-drivers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN controller
Benjamin Close wrote: Hi Folks, A new version of the driver is up which fixes the firmware issues. Seems the wpi-firmware-kmod port was creating corrupt modules. Things should work much better now. Download at the same place, file: 20070131-wpi-freebsd.tar.gz So, when is it going to HEAD? :-) -- Florent Thoumie [EMAIL PROTECTED] FreeBSD Committer signature.asc Description: OpenPGP digital signature
Re: top delay value
typing while :; do :; done. There are a thousand ways No. What I write above is not a fork bomb, it's a single process which is wasting CPU in a busy loop. It's exactly equivalent to top(1) with zero delay, except that top produces some output, while a busy loop does nothing useful at all. I tested different shells and I found out that an exlicit sub shell is required to let the shell fork: while :; do (:); done By the way, you can emulate top(1) with run ps(1) in a shell loop like this (sh/zsh/ksh/bash syntax): while :; do clear; ps -a; sleep 1; done Do get zero delay, simply remove the sleep command from the loop ... That's actually _worse_ than top(1) with zero delay, because kernel cycles are wasted for the fork() and exec() calls, not to mention I/O and other syscalls. An empty shell loop (while :; do :; done) doesn't perform any syscalls into the kernel. Bottom line: Disabling zero-delay in top doesn't buy you anything at all. In fact, it might cause your users to invent work-arounds (for example shell loops) that waste even more resources. So I have to limit the CPU time in /etc/login.conf and :cputime=300:\ invoke cap_mkdb /etc/login.conf. -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
On Wed, Jan 31, 2007 at 03:42:26PM +0100 I heard the voice of Oliver Fromme, and lo! it spake thus: Bottom line: Disabling zero-delay in top doesn't buy you anything at all. Meanwhile, you still can't zero-delay unless you're root. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
In [EMAIL PROTECTED], Dr. Markus Waldeck [EMAIL PROTECTED] typed: typing while :; do :; done. There are a thousand ways No. What I write above is not a fork bomb, it's a single process which is wasting CPU in a busy loop. It's exactly equivalent to top(1) with zero delay, except that top produces some output, while a busy loop does nothing useful at all. I tested different shells and I found out that an exlicit sub shell is required to let the shell fork: while :; do (:); done That's still not a fork bomb. While it creates a process every time through the loop, the process exits before the loop continues, so you've still got just a few processes. Basicaly, it's still a busy loop. A true fork bomb creates an ever-increasing number of processes, typically by forking copies of itself (which led to them being called rabbit jobs when I first ran into one). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: a question regarding sys/shm.h
On Wed, 2007-Jan-31 10:52:02 +, Robert Watson wrote: If we do decide to go ahead with the ABI change, there are a number of other things that should be done simultaneously, such as changing the uid and gid fields to uid_t and gid_t. And mode to mode_t. The uid and gid fields in struct shmid_ds have already been converted, though the ones in struct ipc_perm are obsolete. At a quick glance, everything else is up to date. http://www.opengroup.org/onlinepubs/009695399/ is a useful reference in this area. -- Peter Jeremy pgpQdwA5x7yOc.pgp Description: PGP signature
Re: top delay value
On 1/31/07, Mike Meyer [EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED], Dr. Markus Waldeck [EMAIL PROTECTED]
typed:
typing while :; do :; done. There are a thousand ways
No. What I write above is not a fork bomb, it's a single
process which is wasting CPU in a busy loop. It's exactly
equivalent to top(1) with zero delay, except that top
produces some output, while a busy loop does nothing useful
at all.
I tested different shells and I found out that an exlicit sub shell
is required to let the shell fork:
while :; do (:); done
That's still not a fork bomb. While it creates a process every time
through the loop, the process exits before the loop continues, so
you've still got just a few processes. Basicaly, it's still a busy
loop.
A true fork bomb creates an ever-increasing number of processes,
typically by forking copies of itself (which led to them being called
rabbit jobs when I first ran into one).
mike
--
Mike Meyer [EMAIL PROTECTED]
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
Don't forget that a real fork bomb would fork forking forkers thereby
growing the process overhead and time exponentially!
e.g:
perl -e 'while(1) { fork; };'
--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
diskless boot /usr/local/etc/rc.d/ scripts do not run, why?
Hello everyone, I'm using 6-stable on 4 amd64 machines. One of them has FreeBSD on its local hard drive and others are booted via network with PXE. But I encounter that /usr/local/etc/rc.d/* are not executed during the boot process? Is there some kind of option to change this? Or may be I misconfigured something ? Also, I do not see any messages on console after kernel is loaded into memory. The next thing I see is login: prompt. How to turn on boot messages for network booted machines. I have to say that I use this loader.rc for network boot: load /boot/kernel/kernel echo \007\007 set console=vidconsole autoboot Cheers, Tyoma. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
