Re: Is it possible to create a directory under /dev?
On Wed, May 21, 2008 at 2:06 PM, Oliver Fromme <[EMAIL PROTECTED]> wrote: > Carlos A. M. dos Santos <> wrote: > > I attempted this: > > > > # mkdir /dev/foo > > mkdir: /dev/foo: Operation not supported > > DEVFS is a "virtual" filesystem [...] I already knew that. :-) > > Any suggestions (besides creating it elsewhere, of course)? > > That depends on the purpose. *Why* do you want to create > a subdirectory in /dev? What do you want to do with it? I intended to use it as the mount point for a filesystem. -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it possible to create a directory under /dev?
On Wed, May 21, 2008 at 11:15 AM, Vivek Khera <[EMAIL PROTECTED]> wrote: > > On May 21, 2008, at 8:44 AM, Carlos A. M. dos Santos wrote: > >> I attempted this: >> >># mkdir /dev/foo >>mkdir: /dev/foo: Operation not supported >> >> Any suggestions (besides creating it elsewhere, of course)? > > Assuming you're using a modern FreeBSD (version number would be useful), > /dev does not live on a file system. It exists as its own file system, > controlled by devfs. Check the man page for devfs for details. I'm using 7.0-STABLE. I've read devfs(8), devfs(5) and did not find an answer there. -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suspend/resume on IBM X31
On Mon, May 19, 2008 at 10:24 PM, James Butler <[EMAIL PROTECTED]> wrote: > Greetings > > I am having trouble with suspend/resume on my Thinkpad X31, running > 7.0-STABLE as of April 23. Any help would be appreciated. > > First problem: When I run "acpiconf -s3" from mulituser mode, the > system suspends immediately, without executing /etc/rc.suspend (which > has mode 755); then on resume, I get a panic. [...] I just discovered: http://lists.freebsd.org/pipermail/freebsd-acpi/2008-April/004806.html which fixes the problem for me. Cheers, -James ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Instant reboot with FreeBSD 6.3 and > 2GB RAM
On 12/23/-58 20:59, [EMAIL PROTECTED] wrote: > Hello, > > some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots > on systems with > 2GB RAM (most of them use 4GB). The reboot occurs right > after displaying the FreeBSD loader menu. Most of them told me that they can > boot if they reduce RAM to <= 2GB. > > We are using the following kernel configuration which is based on GENERIC: > http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291&view=markup > > I found out another problem that causes a reboot on my 2GB machine. We are > using a image for the LiveCD which is 64MB great. If i change back mfs_root > size to 63MB all works well, but all above 64MB causes a reboot. > Is there any limitation? > > Could someone help me out of this problem? > > Regards > Volker Hi Volker ;) I'm not quite sure about your 2nd problem and your report is not quite detailed but from your description it looks like loader is causing that. As there's no filesystem available at that time, the loader has to read itself through the filesystem structures. Knowing that, PR misc/108215 comes to mind. I've not been able to check if the issue and the patch to it is right but you may give it a try. Probably somebody with loader and filesystem (ufs) knowledge may answer that question quickly if the patch contained in the PR is right. The report is about 6.2-R but at least I've checked loader code and 7.x code is the same. I came across that report yesterday and was unable to check the calculation. If that is really the case, your problem may be related to that. http://www.freebsd.org/cgi/query-pr.cgi?pr=108215 Assuming the problem report is right, it's about reading huge files by loader reads in wrong sectors. HTH Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_ule performance on single CPU
Sorry for the late reply, but I think there's a technical detail that should be mentioned ... Unga <[EMAIL PROTECTED]> wrote: > My earlier test shows processes in the normal category > can starve processes in real-time category. That's > alarming. It should be get fixed. Note that FreeBSD does not support "hard real time" processing. Strictly speaking no OS does that on PC standard hardware. FreeBSD's idprio/rtprio implementation only affects the decisions of the scheduler, i.e. the assignment of CPU time slices to processes. However, there are other resources beside CPU that influence the execution of processes. For example disk I/O. In other words, if an idle-prio process performs a lot of disk accesses, it creates an I/O bottleneck, and even realtime-prio processes will have to wait because the hardware (disk) is blocked. This problem can be alleviated by using faster and better hardware, e.g. a SCSI RAID-0 disk subsystem or whatever. Besides, for professional audio recording you will also need professional audio hardware (which should include its own buffer memory, among other things), not a consumer card or an el'cheapo USB dongle. Best regards Oliver PS: My notebook at home (Pentium-M, UP, 3 years old) works very well with FreeBSD/i386 RELENG_7 + SCHED_ULE. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing." -- Mother Teresa ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Digitally Signed Binaries w/ Kernel support, etc.
Sorry for replying to an old mail here, but there's an important point that was unanswered so far ... Torfinn Ingolfsen wrote: > David Schwartz wrote: > > > He would face a chicken and egg problem. To make a signed executable > > to set his key to be accepted, he would need his key to already be > > accepted. > > Uhm, if the attacker managed to get a hole in the sustem and get > in, he / she will surely manage to get the necessary tools (a signed > binrary) onto the system. As an added bonus, this is a binary he > created himself, so it works with his key. That wouldn't work. How is he going to sign a binary if he doesn't have the private key? When you set up a system with signed binaries, you usually store the private key somewhere else (on a floppy, USB stick or whatever). Maybe it could even be just a pass- phrase that only exists in the admin's mind, but not on any physical media. So an attacker _cannot_ create a binary with a valid signature. Of course, the kernel doesn't contain the private key either, because you only need the public key to verify the signature. I agree with Peter Wemm: There are legitimate uses for signed binaries. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it possible to create a directory under /dev?
Carlos A. M. dos Santos <> wrote: > I attempted this: > > # mkdir /dev/foo > mkdir: /dev/foo: Operation not supported DEVFS is a "virtual" filesystem, i.e. its contents are not stored on disk, but they're dunamically created by the kernel. Subdirectories only come into existence when a driver creates one for its own purposes, e.g. gmirror creates a /dev/mirror directory. > Any suggestions (besides creating it elsewhere, of course)? That depends on the purpose. *Why* do you want to create a subdirectory in /dev? What do you want to do with it? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd $ dd if=/dev/urandom of=test.pl count=1 $ file test.pl test.pl: perl script text executable ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: syslog console log not logging SCSI problems
Nick Barnes wrote: > Oliver Fromme writes: > > Nick Barnes wrote: > > > One of our FreeBSD boxes has a SCSI controller and disk, which showed > > > problems earlier this week. There was a lot of of chatter from the > > > SCSI driver in /var/log/messages and to the console. However, the > > > console is unattended and we only discovered the problem subsequently > > > because /var/log/console.log didn't show any of the chatter. > > > > The console.* syslog facility only logs real console output, > > i.e. things written to /dev/console. That does _not_ include > > output from the kernel. > > > > For logging kernel output you have to use the kern.* syslog > > facility. > > OK. So when syslogd directs output to the console, it does not also > treat it as console.* output? That's correct. syslogd uses the LOG_CONSOLE flag to distinguish its own output from other console output, otherwise it would run into an infinite loop logging its own output. Best regards Oliver PS: If you're interested in source code, see the printsys() function in src/usr.sbin/syslogd/syslogd.c. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly." -- RFC 2549 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: syslog console log not logging SCSI problems
At 2008-05-20 16:21:01+, Oliver Fromme writes: > Nick Barnes wrote: > > One of our FreeBSD boxes has a SCSI controller and disk, which showed > > problems earlier this week. There was a lot of of chatter from the > > SCSI driver in /var/log/messages and to the console. However, the > > console is unattended and we only discovered the problem subsequently > > because /var/log/console.log didn't show any of the chatter. > > The console.* syslog facility only logs real console output, > i.e. things written to /dev/console. That does _not_ include > output from the kernel. > > For logging kernel output you have to use the kern.* syslog > facility. OK. So when syslogd directs output to the console, it does not also treat it as console.* output? Thanks for this explanation. I'll modify my syslog.conf accordingly. Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Instant reboot with FreeBSD 6.3 and > 2GB RAM
On Wed, May 21, 2008 at 10:01:56AM +0200, [EMAIL PROTECTED] wrote: > Hello, > > some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots > on systems with > 2GB RAM (most of them use 4GB). The reboot occurs right > after displaying the FreeBSD loader menu. Most of them told me that they can > boot if they reduce RAM to <= 2GB. > > We are using the following kernel configuration which is based on GENERIC: > http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291&view=markup > > I found out another problem that causes a reboot on my 2GB machine. We are > using a image for the LiveCD which is 64MB great. If i change back mfs_root > size to 63MB all works well, but all above 64MB causes a reboot. > Is there any limitation? > > Could someone help me out of this problem? Is the mfsroot problem what I've documented here? http://jdc.parodius.com/freebsd/pxeboot_serial_install.html#step7 -- | 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is it possible to create a directory under /dev?
On May 21, 2008, at 8:44 AM, Carlos A. M. dos Santos wrote: I attempted this: # mkdir /dev/foo mkdir: /dev/foo: Operation not supported Any suggestions (besides creating it elsewhere, of course)? Assuming you're using a modern FreeBSD (version number would be useful), /dev does not live on a file system. It exists as its own file system, controlled by devfs. Check the man page for devfs for details. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Instant reboot with FreeBSD 6.3 and > 2GB RAM
On May 21, 2008, at 4:01 AM, [EMAIL PROTECTED] wrote: some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots on systems with > 2GB RAM (most of them use 4GB). The reboot occurs right after displaying the FreeBSD loader menu. Most of them told me that they can boot if they reduce RAM to <= 2GB. For what it's worth, I have run several systems with 4GB RAM on FreeBSD/i386 6.3. The only i386 I have left with this much RAM was recently upgraded to 7.0; the rest of my large RAM systems run FreeBSD/ amd64. I didn't see anything obviously bad in your kernel config. By the way, thanks for making FreeNAS... I use it on my home NFS/AFP server to great success... the only thing I wish it included was the amrstat binary to test my LSI RAID controller status (I just copy it from another 6.3 system I have and it works). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ZFS on root and disk write caching.
I'm playing around with ZFS. Currently, I just use it for storage, with a zpool of 4 sata disks. The system and boot disk is still formatted with UFS. As I'm quite pleased with ZFS features, I'd like to try ZFS on root. The ZFS wiki is quite clear on how to proceed : if the boot and root are on the same disk, you'll have to use bsd labels. The thing is, I read somewhere that ZFS doesn't enable write caching on drives if not used on whole disks. 1. Is it still true on freebsd or just for opensolaris. 2. As the only other(s) label(s) on disk would be the (readonly) boot and swap label, I don't think write caching would be a problem. So how can I tell ZFS it's ok to enable it on the disk (or enable it manualy if necessary and of any use). 3. I'd like to keep the storage pool (zraid1) separated from the system pool (just one disk). The wiki states that we may encounter problems with more than one pool in use : is it still the case ? I know the whole ZFS thing is still experimental, but with it's overall performance, it would really be a shame not to give it its chance. Thanks for your comments. Arnaud Houdelette ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Is it possible to create a directory under /dev?
I attempted this: # mkdir /dev/foo mkdir: /dev/foo: Operation not supported Any suggestions (besides creating it elsewhere, of course)? -- Carlos A. M. dos Santos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Instant reboot with FreeBSD 6.3 and > 2GB RAM
Hello, some users of FreeNAS which is based on FreeBSD 6.3 reported instant reboots on systems with > 2GB RAM (most of them use 4GB). The reboot occurs right after displaying the FreeBSD loader menu. Most of them told me that they can boot if they reduce RAM to <= 2GB. We are using the following kernel configuration which is based on GENERIC: http://freenas.svn.sourceforge.net/viewvc/freenas/branches/0.69/build/kernel-config/FREENAS-i386?revision=3291&view=markup I found out another problem that causes a reboot on my 2GB machine. We are using a image for the LiveCD which is 64MB great. If i change back mfs_root size to 63MB all works well, but all above 64MB causes a reboot. Is there any limitation? Could someone help me out of this problem? Regards Volker -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ubench on v6 a v7
It needs further exploration on different hw as well. I will try but it'll take quite a long time :-) Ivan Voras wrote: Karel Rous wrote: My home computer (no internet access, cannot share results :-) is single processor Athlon 64 on 2250 Mhz/512 KB L2. Visually I have seen that on stable it doesn't behave as speedily as on FreeBSD number 6. I have checked utility in subject (which is probably not the best alternative) and it shows me on memory test half of the speed that was in v6 while using default MALLOC_OPTIONS at each version. There could be certain speed up changing it but IMHO there can not be any we to make it as fast as in previous version. Is there anyone who could make a logical explanation? (I think it has something to do with new malloc optimization for multi processor systems but I might compiled also libc on FreeBSD 7 with wrong options). Even using simple compat6x libc (with libmap.conf) helps to speed up things there. All those measurement are my just my non generalized opinion and I hope I am wrong :-) If you can confirm your results in a clean environment, you might want to talk to jasone@ about this. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
