Re: rc.resume and rc.suspend not executed on 6.2-RELEASE with acpi
Ede Ratzefick wrote: > Hi, > > on my 6.2-RELEASE with acpi runnning, the script /etc/rc.suspend is not > executed when going to S3 and also the /etc/rc.resume when waking up. > Filepermissions are 755. Any ideas? > > BTW: Who's invoking these scripts? I saw it in apmd.conf but as I use acpi > instead of apm this should not be relevant. If you're using the apm -z command or zzz, they will be executed. If you use the physical sleep button, they will not. Fixing this required some API changes as the kernel can't run usermode scripts directly and the button is handled by a kernel driver. If you try 7.0 or -current, you should find this works for you. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to suspend/wake-up a FreeBSD machine?
Mikhail T. wrote: > Hello! > > I managed to suspend some of my computers a few times (using > either ``zzz'' or ``acpiconf -s 1''), but I could never successfully > wake the system up after this, requiring a full reboot. > > What's the proper procedure? I tried the power-button (no effect) and > hitting random keyboard keys (no effect). How is it supposed to work? > > Thanks! The power button or lid is the most common way to wake. Since suspend/resume support needs debugging on many machines, it may not work for you. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Acer Aspire 5601 AWLMi corrupted acpi bytecode
Alexandre Vieira wrote: You can find the asl and iasl output attached. Nope, we couldn't. Try posting a URL to it. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with Cisco (Atheros) Wireless PCI card on IBM Thinkcentre MT-M-8183-T1S
[EMAIL PROTECTED] wrote: Greetings from Merida, Yucatan, Mexico (The Maya Land) Am having problems installing FreeBSD in my University under IBM Thinkcentre MT-M-8183-T1S boxes. I can´t detect the Wireless Cisco (Atheros) PCI lan card. Linux and Windows have no problems recognizing the card but i have problems with FreeBSD 6.0 Here are my dmesg (with and with out ACPI). I don´t know if this is a known issue, but any pointers will be greatly appreciated. I think that the pci3 line shows something but not sure about that. Did you load the if_ath.ko driver? Apparently, disabling ACPI makes no difference so I don't see how this is an ACPI issue. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Marco Calviani wrote: Hi list, 2005/12/2, Bruno Ducrot <[EMAIL PROTECTED]>: I don't see why you can't run powerd more frequently, I do.. Unless your ACPI has a problem that means the transition is slow. I'm sure this could not be done under Linux without a lot of problems (it is required to use the /proc things and it's too slow in that case). I can't imagine that doing 5 (or even 50) syscalls a second is a big CPU load unless there is a specific problem with sysctls or the cpufreq infrastructure. If that's possible being not so intrusive with, say 50 syscalls under FreeBSD, then all I said above is indeed stupid crap. I run powerd like this -> /usr/sbin/powerd -i 90 -r 30 -a adaptive -b adaptive -n adaptive -p 200 Well, i've tried decreasing the polling interval, but there is an increased powerd cpu load: at 100ms polling interval the cpu load is to an astonishing 20% circa, which i think it's too much for a normal use. The sampling rate with ondemand governor in linux kernel is 10ms but cpufreqd is at 0.6% on average cpu load. powerd is not intended to do high speed polling. If you do that, your system will almost never be idle and so we can't save power via Cx. We don't need high speed sampling right now, we need a predictive algorithm. So until someone implements this, it's moot. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Marco Calviani wrote: Hi Bruno, > > 2) sorry what about the point that we were discussing above? The high number of transition you were explaining me, are present in the actual implementation of powerd, and if not, why? It's not present under powerd for the simple fact that to be efficient in term of not being too intrusive (kernel to user data transfers, etc), powerd can only provide a limited number of check per second (at this time, 2 per second). But the current algorithm present in powerd is not well suited in that case. You have to wait one demi-second for the processor being put to full speed if the system was idle before. Are there on the horizon any sort of plans to implement a newer and more efficient algorithm to increase the number of transition per second? Sorry but i've not understood why linux-cpufreqd is able to cope with those without being so intrusive. This work is easy, it's just grunt work implementing and testing to see which is best. See this page for details on how to proceed: http://wikitest.freebsd.org/moin.cgi/powerd Wikitest seems to be down so here's the text only: http://66.102.7.104/search?q=cache:IEXV5nW17ZMJ:wikitest.freebsd.org/moin.cgi/powerd+site:wikitest.freebsd.org+powerd+&hl=en&lr=&strip=1 -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Marco Calviani wrote: Hi Bruno, 2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>: Did you load the cpufreq driver at boot time which include the est driver as said before? It will replace the acpi_perf if appropriate. -- Bruno Ducrot Yes cpufreq is loaded at boot time in /boot/loader.conf .However i don't know how to tell him that i want to load est instead of acpi_perf. est is preferred if supported. But probably est doesn't have a table for his processor so acpi_perf is used. There's nothing wrong with using acpi_perf -- it just gives a BIOS interface to est anyway. You can test this with: hint.acpi_perf.0.disabled="1" This will cause acpi_perf to let est attach. But I suspect est won't. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Bruno Ducrot wrote:
On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
Marco Calviani wrote:
Hi,
2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>:
You have to load the cpufreq.ko module at boot.
Adding that line:
cpufreq_load = "YES"
to /boot/loader.conf
should be OK.
I have that line in that position, and it seems working. The point is
that i would like to change the driver and use (AFAIU) a better driver
for my system (est).
In particular i have:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
Maybe i didn't understood well: but what i have to do to use the Intel
Enhanced SpeedStep driver?
You should send the full output of "sysctl dev.cpu". There is no
cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look
at your dmesg to see if one is probing/attaching.
If you are using acpi and load cpufreq.ko, you've got all the cpufreq
drivers in one package. The right one for your platform will
automatically probe/attach.
powerd need some rework in order to get it working properly. There
is one FreeBSD project on that subject if you are interrested.
Well, thanks i'm very interested, although i'm not at all experienced
in kernel programming
I'm not inside this issue, but it would not be possible to "emulate"
the behaviour of the ondemand governor? (sorry if this question makes
no sense)
I have no idea what you mean by "on-demand governor". The only
automated control of cpu speed is either by the BIOS (which we can't
control) or the TM/TM2 (and that one is heat-based, not load-based).
The ondemand governor is basically an implemation of the following
algorithm:
There is a counter, say count.
at each given fixed intervall:
if (idle less than a watermark) {
frequency full
reinitialise count to 10
} else if (idle more than another watermark) {
decrement count
if count is 0 {
down one step the frequency
}
else reinitilize count to 10
Note that in the latter case, the down step is performed only
after 10 such comparison. In other word, intervall is ten times
larger for the down side than the full frequency one.
This work well when you can perform, say, 20 to 50 transitions per
second. Otherwise, it is pretty bad.
Send me a URL to the datasheet that says Intel implemented this.
That algorithm is basically what powerd does. So just run powerd.
--
Nate
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Marco Calviani wrote: Hi, 2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>: You have to load the cpufreq.ko module at boot. Adding that line: cpufreq_load = "YES" to /boot/loader.conf should be OK. I have that line in that position, and it seems working. The point is that i would like to change the driver and use (AFAIU) a better driver for my system (est). In particular i have: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 Maybe i didn't understood well: but what i have to do to use the Intel Enhanced SpeedStep driver? You should send the full output of "sysctl dev.cpu". There is no cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look at your dmesg to see if one is probing/attaching. If you are using acpi and load cpufreq.ko, you've got all the cpufreq drivers in one package. The right one for your platform will automatically probe/attach. powerd need some rework in order to get it working properly. There is one FreeBSD project on that subject if you are interrested. Well, thanks i'm very interested, although i'm not at all experienced in kernel programming I'm not inside this issue, but it would not be possible to "emulate" the behaviour of the ondemand governor? (sorry if this question makes no sense) I have no idea what you mean by "on-demand governor". The only automated control of cpu speed is either by the BIOS (which we can't control) or the TM/TM2 (and that one is heat-based, not load-based). -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Machine refuses to boot with ACPI enabled by default
Ewald Jenisch wrote: I've got a strange problem wrt. ACPI on one of my boxes under FreeBSD 5.3: The box comes up with ACPI *disabled* by default. Only by manually selecting the menu option that says "Boot with ACPI enabled" can I make the box run ACPI which is kinda annoying when e.g. I remotely reboot the box - after the reboot it comes up without ACPI and as a consequence SMP turned off. To cross check that it's not a config issue I've "diffed" the files in /boot between the machine in question and another one that runs with ACPI enabled by default - absolutely no differences. One box (different hardware) runs with ACPI, this one runs with ACPI disabled by default. Sorry about the long reply time. So my questions are: 1) How can I make this box boot with ACPI enabled by default? In your /boot/loader.conf, set: hint.acpi.0.disabled="0" 2) Why does this box come up without ACPI by default after all? I checked the quirks table and found nothing that should match your machine. Can you send a full dmesg of booting when acpi is automatically disabled? There's usually a quirk message printed if this is the case. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Armada 17xx, ACPI thermal management broken.
Nate Lawson wrote:
Nikolas Britton wrote:
I can't find his name or email address anywhere BUT I think I can do
one better then that. Here are two ASL's that where uploaded to the
ACPI4Linux project:
http://acpi.sourceforge.net/dsdt/tables/Compaq/Armada_1750/Compaq-Armada_1750-686EM_99.1130_A-custom.asl.gz
http://acpi.sourceforge.net/dsdt/tables/Compaq/Armada_1700_1750_3500/Compaq-Armada_1700_1750_3500-686EM_99.1130_A-custom.asl.gz
http://acpi.sourceforge.net/dsdt/tables/Compaq/Armada_1700_1750_3500/Compaq-Armada_1700_1750_3500-686EM_99.1130_A-original.asl.gz
Again, here is a copy of my asl dump:
http://www.nbritton.org/uploads/compaq/armada_17xx.asl
I've attached the diff between the two versions for history. But all
you have to do is download the patched ASL
("Compaq-Armada_1700_1750_3500-686EM_99.1130_A-custom.asl") and
compile/override it. See the handbook or "man acpi" for steps, but the
short of it is:
Oops, diff too big to attach.
--
Nate
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Armada 17xx, ACPI thermal management broken.
Nikolas Britton wrote:
I can't find his name or email address anywhere BUT I think I can do one
better then that. Here are two ASL's that where uploaded to the
ACPI4Linux project:
http://acpi.sourceforge.net/dsdt/tables/Compaq/Armada_1750/Compaq-Armada_1750-686EM_99.1130_A-custom.asl.gz
http://acpi.sourceforge.net/dsdt/tables/Compaq/Armada_1700_1750_3500/Compaq-Armada_1700_1750_3500-686EM_99.1130_A-custom.asl.gz
http://acpi.sourceforge.net/dsdt/tables/Compaq/Armada_1700_1750_3500/Compaq-Armada_1700_1750_3500-686EM_99.1130_A-original.asl.gz
Again, here is a copy of my asl dump:
http://www.nbritton.org/uploads/compaq/armada_17xx.asl
I've attached the diff between the two versions for history. But all
you have to do is download the patched ASL
("Compaq-Armada_1700_1750_3500-686EM_99.1130_A-custom.asl") and
compile/override it. See the handbook or "man acpi" for steps, but the
short of it is:
iasl Compaq-Armada_1700_1750_3500-686EM_99.1130_A-custom.asl
cp DSDT.aml /boot
And add to /boot/loader.conf:
acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/DSDT.aml"
This will load your custom AML at boot time.
--
Nate
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Armada 17xx, ACPI thermal management broken.
Nikolas Britton wrote: When I try it with Linux it worked, in fact, here is a patch for kernel 2.6.7: https://kilobyte.dyndns.info/linux/armada_1700_dsdt_linux-2.6.7.diff.bz2 "Compaq Armada 1700/1750 ACPI/Sound/PM/i2c kernel patch: This patch(2.6.7) fixes the DSDT (broken aml) at bootup (Fan Control works now, changed TZ trip points) and fixes the temperature problem. It also forces the i2c-bus to be enabled at startup and modifies the initial values mpu_io, io, irq, dma and dma16 of the soundcard, therefore there is no need to append them to kernel cmdline anymore (if you want to use oss). Note: The fix is nonpersistent. " So as you see there is already a DSDT/AML/ASL/Whatever fix for it, It just needs to be ported to BSD. AML is OS-independent. It's supplied by the BIOS. Unfortunately, the 'fixed' AML you've found is in binary form. Is there a way I can just disable the ACPI thermal management, then I could use ACPI until someone with more clout and programming know how decides to fix it? Yes, see previously-mentioned hint in loader.conf. It may not help though since once ACPI is active, the BIOS often expects the OS to manage everything so this may just disable your fans. Be careful. + * Intel ACPI Component Architecture + * ASL Optimizing Compiler / AML Disassembler version 20030522 [May 23 2003] + * Copyright (C) 2000 - 2003 Intel Corporation + * Supports ACPI Specification Revision 2.0b + * + * Compilation of "dsdt.asl" - Thu Mar 11 13:09:58 2004 + * + * C source code output + * + */ Can you get the author of this patch to send you the raw "dsdt.asl", instead of the compiled version? If so, send it to me so I can diff against the one I asked you to dump and post. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Armada 17xx, ACPI thermal management broken.
Nikolas Britton wrote: Uwe Laverenz wrote: On Tue, Dec 21, 2004 at 06:25:05AM -0600, Nikolas Britton wrote: Any help would be appreciated on ether fixing this problem or a way to use ACPI but disable the thermal monitoring so the system can control the fan? Try this in /boot/loader.conf: hint.acpi.disabled="thermal" I might be wrong, but I think on the 1750 you should use APM instead of ACPI. I had a 1750 running with FreeBSD 4.x and APM and it worked very well. How?, I added it to my kernel "device apm", "device pmtimer", and "device amp_saver" and rebuilt it and in rc.conf I added apm_enable="YES", apmd_enable="YES" and I greped though default/loader.conf for anything but found nothing, after rebooting the only thing I get from dmesg is "WARNING: apm_saver module requires apm enabled" and when I type in apm I get "apm: can't open /dev/apm: No such file or directory", type in zzz and I get "apm: can't open /dev/apm: No such file or directory" You need to also disable ACPI. After doing that, does it work? I want ACPI!, APM is a last ditch hack to me, the name says it all "Advanced Configuration and Power Interface" there is a reason they switched to it. The 440BX chipset has full support for ACPI and therefore should work with FreeBSD and is a critical problem, what do you think might happen if you disable all your fans on your computer???. Please note that I'm not trying to diss FreeBSD in anyway for it being broken as I understand the issues with the DSDT, AML, and ASL stuff, I just want it to work. APM is not a "last ditch hack." Many PCs, especially from the same era as yours (98-01) have perfect APM support and lousy ACPI support due to the tools and testing just getting up to speed back then. Until recently, Linux declined to support ACPI on systems older than 2001. The chipset may support ACPI but the AML supplied by the OEM is what is the issue here. Post a URL where I can download the AML: acpidump -t -d > hp_armada_1750.asl -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: waking up from zzz(8)
On Tue, 4 May 2004, Mikhail Teterin wrote: > =Use a serial console. Sounds like your system is waking up but not > =fully. The screen may be helped by loading acpi_video. > > I don't think, there is a serial port on this laptop. It has a built-in > "soft-modem", but no free serial port. > > I loaded the acpi_video: > > hw.acpi.video.crt0.active: 0 > hw.acpi.video.tv0.active: 0 > hw.acpi.video.out0.active: 0 > hw.acpi.video.out1.active: 1 > > and will try to zzz again tonight. > > Should I be concerned about any of these values, though: > > hw.acpi.supported_sleep_state: S3 S4 S5 <-- No S1? Nothing surprising here. Few systems have S1. > hw.acpi.power_button_state: S5 > hw.acpi.lid_switch_state: S1 > hw.acpi.standby_state: S1 > hw.acpi.reset_video: 1 > hw.acpi.disable_on_poweroff: 1 I should make these default to min(hw.acpi.supported_sleep_state) instead of just S1. But no problems here either. You can try setting hw.acpi.reset_video=0 to see if it helps your screen resume. Check out the ACPI section from the FreeBSD handbook. Some people put a lot of effort into documenting things and it seems that no one has read it. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: waking up from zzz(8)
On Tue, 4 May 2004, Mikhail Teterin wrote: > On Sunday 02 May 2004 01:23 pm, Nate Lawson wrote: > = On Sun, 2 May 2004, Mikhail Teterin wrote: > = > My Vaio laptop (5.2-current from April 7) duly goes to a quiet sleep > = > when I type `zzz'. > = > > = > Trouble is, I don't know, how to recover from that. If I hit a > = > keyboard key, there is some activity inside, but the screen never > = > turns on and rebooting seems to be my only option. > = > = The power button should wake the system if pressed briefly (don't hold > = it down for more that 2-3 seconds since above that means hard power > = off). Also, the lid switch should work if you close the lid and open > = it again. > > That's what I thought. The laptop seems to wake up -- the lights come > on, but the screen remains blank and the built-in NICs (fxp and ath) > don't respond. > > I upgraded to Saturday's -current (May 1st) -- no changes. Use a serial console. Sounds like your system is waking up but not fully. The screen may be helped by loading acpi_video. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: growfs problem [was Re: Adding a drive in vinum]
> |# growfs /dev/vinum/data > | We strongly recommend you to make a backup before growing the Filesystem > |=20 > | Did you backup your data (Yes/No) ? Yes > | new file systemsize is: 78997019 frags > | growfs: wtfs: write error: 631976157: Inappropriate ioctl for device > |=20 > | And well, it does not work that good... > | Any hints ? > > Ok, no matter what I do, I can't grow this filesystem. I'm wondering if > there's a bug somewhere in growfs or if it's because of vinum or... growfs(8) was never fully updated for UFS2 and probably still uses old disklabel(8) ioctls. This is almost certainly a growfs bug. You should compile it with -g and do a breakpoint to find what operation produces that error message. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Which architecture?
On Fri, 2 Jan 2004, David O'Brien wrote: > On Tue, Dec 30, 2003 at 12:06:06PM -0800, Nate Lawson wrote: > > AMD, Cyrix. The amd64 arch is for the new 64 bit Opterons (i.e. FX64). > > What is "FX64"??? > > "Opteron" is the server 64-bit CPU > "Athlon64 FX51" is the high-end desktop CPU > "Athlon64" is the desktop CPU I can't keep the model #'s straight since they don't make any sense. Not to mention it's impossible to find clock frequencies on amd.com. But that's pretty far OT. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Which architecture?
This message is more suited for freebsd-questions@ On Tue, 30 Dec 2003, Mobasher Sobhan wrote: > I'm a rookie with FreeBSD. I'm confused by which > platform of freebsd could be installed on various IBM > compatible/windows boxes. I have one pc with AMD > Athlon 2GHz and another running on Pentium III. I > assumed i386 (because of "x86"), but when I clicked on > a link on a link "i386" under platforms supported, it > took me to something "Samba" or something related. > Should I get it from "ISO-IMAGES-amd64" directory in > the ftp instead? Or is that for AMD's more advanced > server processors? Install the i386 version of FreeBSD for all ia32 boxes, including Intel, AMD, Cyrix. The amd64 arch is for the new 64 bit Opterons (i.e. FX64). -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck not recognizing vinum filesystem type
On Tue, 9 Dec 2003, DAVID THOMPSON wrote: > I am a relatively new FreeBSD user and I have never posted a request > for help before so I hope I am doing this right and not plugging up the > board with irrelevant and out of context questions. My apologies if I > am. Here is my problem: Welcome to the club! > I have vinum installed on my FreeBSD 5.1-Release box. Vinum starts and > runs fine, but I can't fsck any of the volumes because it says... > > "fsck: Could not determine filesystem type." > > If I do a fsck -T ufs /dev/vinum/??? it will work fine, but it's when I > don't explicity tell fsck what the filesystem type is that I get this > error. You probably didn't disklabel the disk. Do a "man disklabel". In particular, you should do: disklabel -w /dev/vinum/??? auto Edit the disklabel: disklabel -e /dev/vinum/??? Then newfs: newfs /dev/vinum/??? Note that you can potentially trash the system with all this, so please read the section in the handbook on setting up vinum and/or disklabels before doing this on a production system. In fact, test on a scratch disk first. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/vinum-vinum.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: maxusers and random system freezes
On Wed, 4 Dec 2002, Terry Lambert wrote: > Marc Recht wrote: > > Every now and this I hear people saying (mostly you :)) that some problems > > are KVA related or that the KVA must be increased. This makes me a bit > > curious, since I've never seen problems like that on Linux. It sounds for > > me, the not kernel hacker, a bit like something which should be set at boot > > time (or via sysctl). Have you got some pointers which explain FreeBSD's > > KVA ? > > I have written documentation for FreeBSD 4.3/4.4. Unfortunately, > everyone keeps substituting activity for action, and hacking away > at the code, so it doesn't sit still long enough to match any > useful documentation; otherwise, I would have published what I > wrote in Pentad Embedded Systems Journal already (example: the ^^^ I appreciate some of the info you give. But every time you reference a proper noun (person, journal, etc.), Google only gives results of you talking about it in FreeBSD list archives! See also "freebsd mitre netbeui" What kind of conclusion is one to draw from that? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
