Re: 9.0 bsdinstall usage
On 09/23/11 04:09, Fbsd8 wrote: I have installed 9.0 bata2 from cd and the net. In both cases after the completion of the install and rebooting, the bsdinstall scripts still remain on the new installed system. If I interpret the code logic correctly, bsdinstall can ONLY be used for an original install. It's not intended by design to be used any other time, unlike sysinstall. I think the auto script should have code added to remove all traces of the bsdinstall environment at the conclusion of the install. This way bsdinstall fulfills the original design goals and guarantees no one can exec it by accident and kill there running system. It's quite useful after install time for installing new systems (e.g. jails). It also uses approximately zero disk space. -Nathan ___ 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: 9.0 bsdinstall usage
Nathan Whitehorn wrote: On 09/23/11 04:09, Fbsd8 wrote: I have installed 9.0 bata2 from cd and the net. In both cases after the completion of the install and rebooting, the bsdinstall scripts still remain on the new installed system. If I interpret the code logic correctly, bsdinstall can ONLY be used for an original install. It's not intended by design to be used any other time, unlike sysinstall. I think the auto script should have code added to remove all traces of the bsdinstall environment at the conclusion of the install. This way bsdinstall fulfills the original design goals and guarantees no one can exec it by accident and kill there running system. It's quite useful after install time for installing new systems (e.g. jails). It also uses approximately zero disk space. -Nathan bsdinstall/auto logic falls down through the partition hard drive logic with no way to bypass it. It will look for free space on the H.D. you booted from and issue message about no free space, ask you if you want to try another drive and then use the booted drive as target to redo the partitioning again thus scratching your running system. In the normal sense there is no way bsdinstall can be used to create jails. A jail does not occupies a whole H.D nor do you boot a jail as a standalone host. The qjail port is there for the purpose of creating and administration of jails. Its not a question of how much space bsdinstall occupies on the H.D. after the original install. Its that some poor soul may try to use it and trash there newly installed running system by accident. And if there were multiple os's on that H.D. there all gone in a heart beat. We have to protect the poor user from them selfs doing stupid things. As I understand it bsdinstall is a replacement for sysinstall. Sysinstall tried to be everything to everybody and turned into a can of worms. There is nothing wrong about limiting bsdinstall to a roll of original installs only. KISS These 2 statements should be added at the end of bsdinstall/auto to complete the clean up of the install process. rm /usr/sbin/bsdinstall rm -rf /usr/libexec/bsdinstall Another benefit of doing this is it will no longer be necessary to create man pages for bsdinstall. ___ 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: 9.0 bsdinstall usage
Daniel O'Connor wrote: On 23/09/2011, at 11:39, Fbsd8 wrote: I have installed 9.0 bata2 from cd and the net. In both cases after the completion of the install and rebooting, the bsdinstall scripts still remain on the new installed system. If I interpret the code logic correctly, bsdinstall can ONLY be used for an original install. It's not intended by design to be used any other time, unlike sysinstall. I think the auto script should have code added to remove all traces of the bsdinstall environment at the conclusion of the install. This way bsdinstall fulfills the original design goals and guarantees no one can exec it by accident and kill there running system. The binary is installed by default, but there it isn't run at startup. If it is being run then I would expect you are booting off your install media again by accident. -- Daniel O'Connor You did not read my post correctly. I dont say bsdinstall is run every time I boot. I said the bsdinstall scripts still remain on the new installed system. The point I was making is it should not remain. ___ 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: 9.0 bsdinstall usage
Adrian Chadd wrote: On 23 September 2011 10:09, Fbsd8 fb...@a1poweruser.com wrote: I have installed 9.0 bata2 from cd and the net. In both cases after the completion of the install and rebooting, the bsdinstall scripts still remain on the new installed system. If I interpret the code logic correctly, bsdinstall can ONLY be used for an original install. It's not intended by design to be used any other time, unlike sysinstall. I think the auto script should have code added to remove all traces of the bsdinstall environment at the conclusion of the install. This way bsdinstall fulfills the original design goals and guarantees no one can exec it by accident and kill there running system. Have you thought about filing PRs for your installer suggestions, just so they don't get lost? I've just filed a bsdinstaller PR for a wifi config bug; I'm likely going to file a few more PRs based on my interaction with the installer. Thanks, Adrian Yes I have been submitting PR's. ___ 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: 9.0 bsdinstall usage
On 23/09/2011, at 23:03, Fbsd8 wrote: The binary is installed by default, but there it isn't run at startup. If it is being run then I would expect you are booting off your install media again by accident. -- Daniel O'Connor You did not read my post correctly. I dont say bsdinstall is run every time I boot. I said the bsdinstall scripts still remain on the new installed system. The point I was making is it should not remain. I think that is pretty debatable, you could certainly use them to install onto a new disk - say you had a machine you couldn't boot the install media off so you put the disk in your PC. Also, it should be very difficult to destroy your installed setup while you're actually booted into it because GEOM will prevent partition changes to mounted disks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: 9.0 bsdinstall usage
On 9/23/11 9:23 AM, Fbsd8 wrote: We have to protect the poor user from them selfs doing stupid things. I find your presumptuous users are stupid comment rather offensive. But, it did remind me of one of my favorite quotes: UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project ___ 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: SCSI descriptor sense changes, testing needed
On Thu, Sep 22, 2011 at 01:33:05PM -0600, Kenneth D. Merry wrote: I have attached a set of patches against head that implement SCSI descriptor sense support for CAM. Descriptor sense is a new sense (SCSI error) format introduced in the SPC-3 spec in 2006. FreeBSD doesn't currently support it. Seagate's new 3TB SAS drives come with descriptor sense enabled by default, and it's possible that other newer drives do as well. Because all the sense key, additional sense code, and additional sense code qualifier fields are in different places, the CAM error recovery code will not do the right thing when it gets descriptor sense. These patches do bump up the size of struct scsi_sense_data, and so I have incremented CAM_VERSION as well. I have discussed this with re@, and it looks like we'll be putting the changes in before 9.0, so it ships with support for newer SCSI devices. Hi Ken, as far as I understand this also requires consumers of scsi_sense_data and SSD_FULL_SIZE etc in userland to be recompiled. So while you are at breaking the API and ABI of CAM anyway, could you please take the opportunity to change CAM_XPT_PATH_ID and CAM_BUS_WILDCARD to not use the same value so incorrect uses will fail? Currently, there seems to be a lot of confusion when to use which one, including camcontrol(8) just encoding this as -1: /* * We don't want to rescan or reset the xpt bus. * See above. */ if ((int)bus_result-path_id == -1) continue; Moreover, AFAICT CAM_XPT_PATH_ID corresponds to what the ANSI CAM Draft refers to as XPT Path ID and specifies a value of 0xff for. Marius ___ 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: 9.0 beta2 the new bsdinstaller
Fbsd8 wrote: 6. At the Complete screen when the reboot option is selected the cd/dvd drive should automatically open so the install media can be removed just like sysinstall does. If disc1.iso or dvd.iso was installed to memstick and used to boot from to install the system, then a message screen should pop out saying the memstick has to be removed now before the reboot starts. Don't let the reboot occur until the memstick is removed. Do NOT alter! More often than not, (1) you keep floppies, optical discs, and memory sticks in your computer without intending to boot from them, and (2) you'll want to use your BIOS's boot-once functionality (press a specific keyboard button to bring up the media choser menu for that boot; otherwise boot from the hard drives) whenever you do want to boot from floppies, optical discs, or memory sticks. ___ 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
ath / 802.11n performance issues and timer code
Hi Alexander, I've been looking at issues with 802.11n RX performance on these MIPS24k based MIPS boards. After doing a bit of digging, I discovered what looked like strange scheduler issues where the RX and TX completion schedulers weren't being invoked quickly. The ath driver schedules these functions using taskqueues. Here's the time keeper configuration for my mips24k board: # sysctl kern.eventtimer kern.eventtimer.choice: MIPS32(800) kern.eventtimer.et.MIPS32.flags: 7 kern.eventtimer.et.MIPS32.frequency: 36000 kern.eventtimer.et.MIPS32.quality: 800 kern.eventtimer.periodic: 1 kern.eventtimer.timer: MIPS32 kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 When I set kern.eventtimer.periodic=1, the 11n TX/RX performance suddenly jumps to where it should be. Would you mind helping me figure out what the problem is? I didn't think kern.eventtimer.periodic was needed? Thanks, Adrian ___ 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: Choosing between DELAY(useconds) and pause()
On Thu, 2011-09-22 at 20:07 +0200, Hans Petter Selasky wrote: On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: It appears that the pause() function cannot be used in driver functions which are invoked early in the boot process. Is there is a kernel api which a device driver can use to determine whether to use pause() or DELAY(), for delays which are say greater than 10hz - may be even 1 hz ? Maybe you want to use something like this: if (cold) DELAY() else pause() In your code. Note that this still shouldn't be done in your suspend/resume paths, as cold isn't set there, however there also appears to be no guarantee that pause() will ever return (as you could be running after the timer has been suspended, or before it resumes). I'm not sure what the correct answer is for suspend/resume code. Gavin ___ 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
panic without swap partition in single user mode 9.0-BETA2 spoiling cp-ace = 1
Hello, maybe this is a bad thing to do, I'm trying to to change the active partition on the device (ada1) which is booted from in single user mode. I changed kern.geom.debugflags to 16. Calling fdisk with -a or -u flags, panics immediately: panic: spoiling cp-ace = 1 Maybe it is related to kern/112707, but I don't know. The panic only occuers, if there is no swap partition enabled. Doing a swapon /dev/ada1s4b for instance before the fdisk call does not yield to the panic. I could not find any mention of this issue in the fdisk(8) or swapon(8), geom(4) has a section about spoiling, but I couldn't figure out how this is related to swaping or fdisk. I can't remember having to use swapon before using fdisk in the past (but I'm not sure...) If this is a requirement, I think it should be documented somewhere in fdisk(8). Note that the panic does also not occur if kern.geom.debugflags is 0. uname -a FreeBSD antec 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Sat Sep 17 12:51:24 CEST 2011 root@antec:/usr/obj/usr/src/sys/GENERIC amd64 Below is a backtrace and the kernel config, I can reproduce the panic every time in this setup, how should I proceed to get more information form the dump? Greetings Peter P.S. FreeBSD-9 rocks! kernel backtrace: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: 118Terminated 118. 118Sep 22 18:43:53 antec syslogd: exiting on signal 15 6pid 2139 (hald), uid 560: exited on signal 10 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...3 1 1 0 0 done All buffers synced. lock order reversal: 1st 0xfe000d2a7bd8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1194 2nd 0xfe000d31ebd8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2246 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vputx() at vputx+0x328 dounmount() at dounmount+0x2a8 vfs_unmountall() at vfs_unmountall+0x4c kern_reboot() at kern_reboot+0x7f9 sys_reboot() at sys_reboot+0x68 amd64_syscall() at amd64_syscall+0x3ba Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40e9ac, rsp = 0x7fffd6d8, rbp = 0x9b --- lock order reversal: 1st 0xfe0006ad4818 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1194 2nd 0xfe0006ab0458 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2134 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 __lockmgr_args() at __lockmgr_args+0xdc6 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x13f devfs_root() at devfs_root+0x4d dounmount() at dounmount+0x48e vfs_unmountall() at vfs_unmountall+0x4c kern_reboot() at kern_reboot+0x7f9 sys_reboot() at sys_reboot+0x68 amd64_syscall() at amd64_syscall+0x3ba Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40e9ac, rsp = 0x7fffd6d8, rbp = 0x9b --- Uptime: 23m40s Rebooting... cpu_reset: Stopping other CPUs Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-BETA2 #0: Sat Sep 17 12:51:24 CEST 2011 root@antec:/usr/obj/usr/src/sys/GENERIC amd64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2400.05-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6f7 Family = 6 Model = f Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4082712576 (3893 MB) Event timer LAPIC quality 400 ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor
Re: 9.0 bata2 keymap
On Sat, 2011-09-17 at 12:24 -0400, Fbsd8 wrote: Changing the cancel button in the kbdmap command to skip, does not address the problem, which is the lack of knowledge of the standard bsdinstall user. I've been using Freebsd since 4.0 and never used the kbdmap command or for that matter even knew it existed. Interesting. Sysinstall has asked for country information and then asked you to choose a keymap (using kbdmap) if you selected a non-default country as the first two questions (i.e. before you get the sysinstall menu) since 6.1. Would that be a good solution still? Some of the other points brought up later about wanting to switch between two different keymaps seem sensible too, though I don't initially see how that would be possible. Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ 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: 9.0 bata2 keymap
I don't think not asking the question is the right answer. Asking about the keyboard layout during installation is the right thing to do; working with the wrong one is difficult and not everyone has a standard US keyboard. I think the problem is that the keymap names are kind of obscure, making it hard for users who aren't already familiar with FreeBSD internals to know which one to pick. Many Linux installers ask for a keymap during installation, but they give fairly clear names for the keymaps like US English 105-key, making it easy to pick one that's likely to work. When I installed FreeBSD-9.0-BETA it took me two tries to find a layout that works because it's far from clear what will yield normal behavior. I tried the United States of America Traditional UNIX Workstation one first (traditional! It must be standard, right?) and found I had no working Ctrl key. Eventually I landed on United States of America ISO-8859-1, which worked, but I'm not sure it's reasonable to expect a new user to know what ISO-8859-1 is and whether they have it. Surely we can name these layouts a bit more clearly? I think that would solve most of the problem. I would offer a patch but I'm the wrong person to do it, since they make no sense to me. ;) ___ 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
Boot FreeBSD-current on macbook from USB stick ?
Has anybody managed this on an unadultered MacBook ? I've tried with rEFIt and it sees the FreeBSD, but it doesn't boot for me :-/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Boot FreeBSD-current on macbook from USB stick ?
On 09/23/11 15:12, Poul-Henning Kamp wrote: Has anybody managed this on an unadultered MacBook ? I've tried with rEFIt and it sees the FreeBSD, but it doesn't boot for me :-/ I have. There's some information which isn't easy co come by: Macs use a non-standard EFI boot process. They search for an HFS+ partition, which has a special blessed file containing the EFI bootloader. They also set the graphics hardware into framebuffer mode. To boot a standards-compliant EFI OS, you'd have to have an HFS+ partition containing an EFI program that sets the graphics hardware back to text mode, then exits, dropping you back to the EFI boot console. You can boot in legacy BIOS mode, which I do. You have to create an MBR/BSD label installation, as if you have a GPT, the firmware will do what I described above. Now, the mac firmware will wait 30 seconds before doing the legacy BIOS boot. You can get around this by holding ALT at power on, and selecting windows (*sigh*). I have the following partition scheme: MBR---BSD---+---ZFS | +---Swap I do not use refit. signature.asc Description: OpenPGP digital signature
Re: Boot FreeBSD-current on macbook from USB stick ?
In message 4e7cf115.5000...@shadowsun.net, Eric McCorkle writes: You can boot in legacy BIOS mode, which I do. You have to create an MBR/BSD label installation, as if you have a GPT, the firmware will do what I described above. Now, the mac firmware will wait 30 seconds before doing the legacy BIOS boot. You can get around this by holding ALT at power on, and selecting windows (*sigh*). I have the following partition scheme: MBR---BSD---+---ZFS | +---Swap I do not use refit. That does not seem to work for me, I have USB stick with a NanoBSD on it, and it never gets recognized by the macbook, so there is no 'windows' to select... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: ath / 802.11n performance issues and timer code
On 23.09.2011 18:29, Adrian Chadd wrote: I've been looking at issues with 802.11n RX performance on these MIPS24k based MIPS boards. After doing a bit of digging, I discovered what looked like strange scheduler issues where the RX and TX completion schedulers weren't being invoked quickly. The ath driver schedules these functions using taskqueues. Here's the time keeper configuration for my mips24k board: # sysctl kern.eventtimer kern.eventtimer.choice: MIPS32(800) kern.eventtimer.et.MIPS32.flags: 7 kern.eventtimer.et.MIPS32.frequency: 36000 kern.eventtimer.et.MIPS32.quality: 800 kern.eventtimer.periodic: 1 kern.eventtimer.timer: MIPS32 kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 When I set kern.eventtimer.periodic=1, the 11n TX/RX performance suddenly jumps to where it should be. Would you mind helping me figure out what the problem is? I would be glad to help, but at this moment I am not sure how network traffic related to timer. May be wireless has some specifics, but for wired adapters traffic processing happens on network interrupts. I didn't think kern.eventtimer.periodic was needed? It should not be needed. Have you tried to set kern.eventtimer.idletick=1 instead? kern.eventtimer.periodic=1 on UP system effectively includes kern.eventtimer.idletick=1. kern.eventtimer.idletick=0 may somewhat increase interrupts overhead due to need to reprogram timer before context switch, but under high interrupt rate (about few KHz) kernel should dynamically switch to quick mode skipping it. -- Alexander Motin ___ 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: Boot FreeBSD-current on macbook from USB stick ?
On Fri, Sep 23, 2011 at 1:56 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 4e7cf115.5000...@shadowsun.net, Eric McCorkle writes: You can boot in legacy BIOS mode, which I do. You have to create an MBR/BSD label installation, as if you have a GPT, the firmware will do what I described above. Now, the mac firmware will wait 30 seconds before doing the legacy BIOS boot. You can get around this by holding ALT at power on, and selecting windows (*sigh*). I have the following partition scheme: MBR---BSD---+---ZFS | +---Swap I do not use refit. That does not seem to work for me, I have USB stick with a NanoBSD on it, and it never gets recognized by the macbook, so there is no 'windows' to select... What does gpart list say for the USB stick? -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: Boot FreeBSD-current on macbook from USB stick ?
In message CAGH67wQ+i3SzjHFK=xgfovskenxzrma9hcerp8y8dqnuqt4...@mail.gmail.com , Garrett Cooper writes: That does not seem to work for me, I have USB stick with a NanoBSD on it, and it never gets recognized by the macbook, so there is no 'windows' to select... What does gpart list say for the USB stick? critter# gpart list da0 Geom name: da0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 7925758 first: 63 entries: 4 scheme: MBR Providers: 1. Name: da0s1 Mediasize: 1048674816 (1G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r0w0e0 attrib: active rawtype: 165 length: 1048674816 offset: 32256 type: freebsd index: 1 end: 2048255 start: 63 2. Name: da0s2 Mediasize: 1048674816 (1G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1048739328 Mode: r0w0e0 rawtype: 165 length: 1048674816 offset: 1048739328 type: freebsd index: 2 end: 4096511 start: 2048319 3. Name: da0s3 Mediasize: 1548288 (1.5M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2097414144 Mode: r0w0e0 rawtype: 165 length: 1548288 offset: 2097414144 type: freebsd index: 3 end: 4099535 start: 4096512 Consumers: 1. Name: da0 Mediasize: 4057988608 (3.8G) Sectorsize: 512 Mode: r0w0e0 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: Boot FreeBSD-current on macbook from USB stick ?
On Friday 23 September 2011 21:12:52 Poul-Henning Kamp wrote: Has anybody managed this on an unadultered MacBook ? I've tried with rEFIt and it sees the FreeBSD, but it doesn't boot for me :-/ Hi, Yes - you need to put a dummy MBR there even if using GPT layout. There are some tools in ports that can do that. --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: ath / 802.11n performance issues and timer code
On 24 September 2011 05:38, Alexander Motin m...@freebsd.org wrote: When I set kern.eventtimer.periodic=1, the 11n TX/RX performance suddenly jumps to where it should be. Would you mind helping me figure out what the problem is? I would be glad to help, but at this moment I am not sure how network traffic related to timer. May be wireless has some specifics, but for wired adapters traffic processing happens on network interrupts. Well, here the interrupt handler just sets up some deferred tasks to run via taskqueue_schedule(). This isn't the only driver which does this - I think the gige/10gige NICs also do this. I didn't think kern.eventtimer.periodic was needed? It should not be needed. Have you tried to set kern.eventtimer.idletick=1 instead? I just tested it - it has the same effect. kern.eventtimer.periodic=1 on UP system effectively includes kern.eventtimer.idletick=1. kern.eventtimer.idletick=0 may somewhat increase interrupts overhead due to need to reprogram timer before context switch, but under high interrupt rate (about few KHz) kernel should dynamically switch to quick mode skipping it. The clock rate interrupt difference is quite startling - at 150mbit 11n bridging (from wlan0 - arge0 wired) the clock interrupt rate is around 300/sec for idletick=0, and about 1150/sec for idletick=1. The other thing to keep in mind is that the wlreless NIC isn't interrupting per RX or TX completed packet. So although I'm doing ~ 19,000 pps, it's only interrupting me ~ 390 times a second. Adrian ___ 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: ath / 802.11n performance issues and timer code
On 24.09.2011 04:13, Adrian Chadd wrote: On 24 September 2011 05:38, Alexander Motin m...@freebsd.org wrote: When I set kern.eventtimer.periodic=1, the 11n TX/RX performance suddenly jumps to where it should be. Would you mind helping me figure out what the problem is? I would be glad to help, but at this moment I am not sure how network traffic related to timer. May be wireless has some specifics, but for wired adapters traffic processing happens on network interrupts. Well, here the interrupt handler just sets up some deferred tasks to run via taskqueue_schedule(). This isn't the only driver which does this - I think the gige/10gige NICs also do this. OK, but how taskqueue related to the timer? Taskqueue uses SWI that are called in separate thread and except swi4: clock AFAIR they are not anyhow related to the timer. I didn't think kern.eventtimer.periodic was needed? It should not be needed. Have you tried to set kern.eventtimer.idletick=1 instead? I just tested it - it has the same effect. Interesting. So either it is what I've described below (but it's strange, I have doubt it may consume so much time, at least I haven't seen it on x86), or network traffic is still somehow depends on timer events and timer events are delayed more then needed. kern.eventtimer.periodic=1 on UP system effectively includes kern.eventtimer.idletick=1. kern.eventtimer.idletick=0 may somewhat increase interrupts overhead due to need to reprogram timer before context switch, but under high interrupt rate (about few KHz) kernel should dynamically switch to quick mode skipping it. The clock rate interrupt difference is quite startling - at 150mbit 11n bridging (from wlan0 - arge0 wired) the clock interrupt rate is around 300/sec for idletick=0, and about 1150/sec for idletick=1. The numbers themselves look fine. 1150 int/sec should mean 1000 of hz and 127 of stathz. Lower rate with idletick=0 means that eventtimer subsystem is dropping some timer ticks. The other thing to keep in mind is that the wlreless NIC isn't interrupting per RX or TX completed packet. So although I'm doing ~ 19,000 pps, it's only interrupting me ~ 390 times a second. So low interrupt rate means large queuing, that should make bandwidth even less affected by side influences. Can you try to build kernel with KTR_SPARE2 KTR and send me a trace when the traffic flows. I would like to check whether timer events are generated close to a proper time. -- Alexander Motin ___ 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: ath / 802.11n performance issues and timer code
I'll get you a trace soon. I noticed a much smaller but valid looking effect when doing this on my eeepc. If I enable idletick, I get an extra 15-25mbit/sec 11n TX throughput. kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 35003954 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.idletick: 1 kern.eventtimer.singlemul: 4 That's running r222417 -HEAD though. Thanks, adrian ___ 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
