Re: kexec or similar for FreeBSD
On (21/06/2011 16:05), Warner Losh wrote: On Jun 21, 2011, at 2:40 PM, Gleb Kurtsou wrote: On (16/06/2011 22:35), Russell Cattelan wrote: On 6/16/11 3:06 PM, Gleb Kurtsou wrote: On (16/06/2011 13:32), Russell Cattelan wrote: I have been contacted about possibly implementing a fast reboot mechanism for FreeBSD similar to kexec on Linux. I have just started looking into how this accomplished so I figured a note to freebsd hackers would also be a good place to ask for comments. Has anybody looked at doing something like kexec? I was working on similar project some time ago. First of all you have to leave hardware in known good state for a new kernel. Reseting devices can be generally accomplished by unloading corresponding kernel modules (even if they are compiled in kernel). The biggest problem for me was timers and programmable interrupt controller. I didn't make it work properly, but my goals where much wider than replacing with another FreeBSD kernel. Aim was to restore initial BIOS state as much as possible. What were your goals beyond booting a new kernel? I think getting back to a known BIOS state is kinda required to get a kernel through the boot process. From what I can tell the main goal of kexec is to avoid the process of re-initializing the hardware via BIOS. Yes it's required to be able load device drivers once again. I had to get back BIOS USB support, both USB HID devices and USB mass storage access with int 13h. Which is not documented by BIOS vendors. So decision was made not to boot full OS, but to extend loader and boot FreeBSD kernel only if necessary rebooting afterwards. Well, if it is really kexec, wouldn't the kernel be able to use its drivers to load the stuff, rendering the BIOS state irrelevant? Or were you kexecing /boot/loader, which would be a lot harder... The project I've mentioned was about implementing a solution similar to kexec-loader, it boots Linux kernel and uses kexec to boot another loader or Linux kernel. Linux kernel execution starts in real mode(!) unlike FreeBSD. The project was very different from FreeBSD-kexec I describe. I'd like to avoid running /boot/loader booting FreeBSD kernel directly and to use full-fledged OS to load new kernel and modules. http://www.solemnwarning.net/kexec-loader/ Is it the right thing to do for FreeBSD. I'm concerned that the way FreeBSD handles early kernel modules (loaded via the boot loader) vs linux which does everything via initrd is going to be a problem. I find loader code easy work with. You could write dummy filesystem implementation for libstand. So that customized loader will load both kernel and modules yet while running FreeBSD. Your reboot procedure wouldn't even use any BIOS io interrupts. Linux boot is a real mess imho. So it is possible to get back to the loader once the kernel is booted? So the running kernel could load the new kernel / modules and then jump back to the loader to start the boot process. I meant that you can allocate memory and load new kernel and modules still while running original FreeBSD kernel, i.e. reuse loader code to load elf objects, pass boot args to kernel, etc. That would require very specific memory layout and proper BIOS memory map (SMAP). Unload all drivers, disable timers and interrupt controller. Then you can start new kernel directly without going to loader, thus avoiding real mode crap, finding original boot device BIOS number and boot0+boot altogether. Yea, what he said :) I'm not even sure int 13h will always be functional after device was claimed by FreeBSD driver. It's not the case for USB, ATA should work, booting from anything else is likely to be a problem. Yup. Once you're in the kernel, all bets are off on BIOS functions on amd64 (you can't go back to a state where you can call the BIOS without resetting the CPU aka rebooting). Many bets are off on i386. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
IPI and I/O interrupts
Hi, I would like to understand little bit about the FreeBSD interrupt handling on x86. When a cpu is processing an IPI, let's say cpu is running IPI_STOP handler, are I/O interrupts like the timer interrupt disabled ? Conversely if the cpu is holding a spinlock, which means it has disabled interrupts, can it process an IPI. My understanding is executing cli instruction disables the maskable interrupts. I was wondering if IPIs are part of that. Thanks, Sushanth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
speech reconition
After seeing one to many ads for Dragon I have decided to see what can done on my main (and only) machine which runs FB exclusively please note I have a speech impairment but when I tried a very early version of Dragon in I think 1989 or 1990 it got 90% of what I said with no training (and my speech has improved since then and I am sure it has also)... I will be using this mostly for command line input (tcsh) but the main purpose of that is to be a java developer who hates IDE's additionally I will be using it for OpenOffice and perhaps browser address bar and forms (I will move the mouse thank you ;-))... I see three possible routes which is best: 1. Use something from ports (it is ok if I have to write a few glue scripts) 2. Use wine but I have never gotten anything to work correctly on it 3. Install virtual box and then install windows 7 and hope that the sound card mic works with it and buy Dragon and then use PuTTY to get to the command line of the host OS My preference is in the same order if possible ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
threads runtime value is incorrect (tc_cpu_ticks() problem)
Hi, I've tested FreeBSD-current from June 16 2011 on x86 (AMD Elan SC400). I found out that a sum of runtimes of all threads is about 120 minutes after 180 minutes of system uptime and the difference is getting worse with time. The problem is in tc_cpu_ticks() implementation which takes into acount just one timecounter overflow, but in tested BSP (16-bit hardware counter) very often more than one overflow occured between two tc_cpu_ticks() calls. I understand that 16-bit timecounter is a real relict nowadays, but I would like to solve the problem somehow reasonably. I have a few questions. According to description in definition of timecounter structure (sys/timetc.h), tc_get_timecount() should read the counter and tc_counter_mask should mask off any unimplemented bits. In tc_cpu_ticks(), if ticks count returned from tc_get_timecount() overflows then (tc_counter_mask + 1) is added to result. However, timecounter hardware can be initialized to value from interval (0, tc_counter_mask, so if the description of tc_get_timecount() doesn't lie then adding (tc_counter_mask + 1) value at all times is not correct. Better description which satisfies tc_cpu_ticks() implementation is that tc_get_timecount() should count the ticks in interval 0, tc_counter_mask. That's what i8254_get_timecount() (in sys/x86/isa/clock.c) does really. However, if tc_get_timecount() should count the ticks (and doesn't read the counter) then it can count the ticks in full uint64_t range? And tc_cpu_ticks() implementation could be very simple (not masking, not overflow checking). In i8254_get_timecount(), it is enough to change global variable 'i8254_offset' and local variable 'count' from uint16_t to uint64_t type. Now, cpu_ticks() (whichs point to tc_cpu_ticks() by default) is called from mi_switch() which must be called often enough to satisfy tc_cpu_ticks() implementation (recognize just one timecounter overflow). That limits some of system parameters (at least hz selection). It looks that tc_counter_mask is a little bit misused? Maybe, tc_cpu_ticks() is only used for back compatibility and new system should use set_cputicker() to change this default? Thanks for some help to better understand that. Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: threads runtime value is incorrect (tc_cpu_ticks() problem)
On 2011-06-22 12:33, Svatopluk Kraus wrote: Hi, I've tested FreeBSD-current from June 16 2011 on x86 (AMD Elan SC400). I found out that a sum of runtimes of all threads is about 120 minutes after 180 minutes of system uptime and the difference is getting worse with time. The problem is in tc_cpu_ticks() implementation which takes into acount just one timecounter overflow, but in tested BSP (16-bit hardware counter) very often more than one overflow occured between two tc_cpu_ticks() calls. I understand that 16-bit timecounter is a real relict nowadays, but I would like to solve the problem somehow reasonably. I have a few questions. According to description in definition of timecounter structure (sys/timetc.h), tc_get_timecount() should read the counter and tc_counter_mask should mask off any unimplemented bits. In tc_cpu_ticks(), if ticks count returned from tc_get_timecount() overflows then (tc_counter_mask + 1) is added to result. However, timecounter hardware can be initialized to value from interval (0, tc_counter_mask, so if the description of tc_get_timecount() doesn't lie then adding (tc_counter_mask + 1) value at all times is not correct. Better description which satisfies tc_cpu_ticks() implementation is that tc_get_timecount() should count the ticks in interval0, tc_counter_mask. That's what i8254_get_timecount() (in sys/x86/isa/clock.c) does really. However, if tc_get_timecount() should count the ticks (and doesn't read the counter) then it can count the ticks in full uint64_t range? And tc_cpu_ticks() implementation could be very simple (not masking, not overflow checking). In i8254_get_timecount(), it is enough to change global variable 'i8254_offset' and local variable 'count' from uint16_t to uint64_t type. Now, cpu_ticks() (whichs point to tc_cpu_ticks() by default) is called from mi_switch() which must be called often enough to satisfy tc_cpu_ticks() implementation (recognize just one timecounter overflow). That limits some of system parameters (at least hz selection). It looks that tc_counter_mask is a little bit misused? Maybe, tc_cpu_ticks() is only used for back compatibility and new system should use set_cputicker() to change this default? Thanks for some help to better understand that. I'm by no means an expert in this field - but your mentioning of AMD Elan SC400 triggered some old knowledge about the AMD Elan SC520. If you have a look at the sys/i386/i386/elan-mmcr.c Function init_AMD_Elan_sc520() adresses the fact that the i8254 has a nonstandard frequency with the AMD Elan SC520 at least - could it be the same with the SC400 ? Just a thought ? /Uffe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: threads runtime value is incorrect (tc_cpu_ticks() problem)
On Wed, Jun 22, 2011 at 1:40 PM, Uffe Jakobsen u...@uffe.org wrote: On 2011-06-22 12:33, Svatopluk Kraus wrote: Hi, I've tested FreeBSD-current from June 16 2011 on x86 (AMD Elan SC400). I found out that a sum of runtimes of all threads is about 120 minutes after 180 minutes of system uptime and the difference is getting worse with time. The problem is in tc_cpu_ticks() implementation which takes into acount just one timecounter overflow, but in tested BSP (16-bit hardware counter) very often more than one overflow occured between two tc_cpu_ticks() calls. I understand that 16-bit timecounter is a real relict nowadays, but I would like to solve the problem somehow reasonably. I have a few questions. According to description in definition of timecounter structure (sys/timetc.h), tc_get_timecount() should read the counter and tc_counter_mask should mask off any unimplemented bits. In tc_cpu_ticks(), if ticks count returned from tc_get_timecount() overflows then (tc_counter_mask + 1) is added to result. However, timecounter hardware can be initialized to value from interval (0, tc_counter_mask, so if the description of tc_get_timecount() doesn't lie then adding (tc_counter_mask + 1) value at all times is not correct. Better description which satisfies tc_cpu_ticks() implementation is that tc_get_timecount() should count the ticks in interval0, tc_counter_mask. That's what i8254_get_timecount() (in sys/x86/isa/clock.c) does really. However, if tc_get_timecount() should count the ticks (and doesn't read the counter) then it can count the ticks in full uint64_t range? And tc_cpu_ticks() implementation could be very simple (not masking, not overflow checking). In i8254_get_timecount(), it is enough to change global variable 'i8254_offset' and local variable 'count' from uint16_t to uint64_t type. Now, cpu_ticks() (whichs point to tc_cpu_ticks() by default) is called from mi_switch() which must be called often enough to satisfy tc_cpu_ticks() implementation (recognize just one timecounter overflow). That limits some of system parameters (at least hz selection). It looks that tc_counter_mask is a little bit misused? Maybe, tc_cpu_ticks() is only used for back compatibility and new system should use set_cputicker() to change this default? Thanks for some help to better understand that. I'm by no means an expert in this field - but your mentioning of AMD Elan SC400 triggered some old knowledge about the AMD Elan SC520. If you have a look at the sys/i386/i386/elan-mmcr.c Function init_AMD_Elan_sc520() adresses the fact that the i8254 has a nonstandard frequency with the AMD Elan SC520 at least - could it be the same with the SC400 ? You are correct, AMD Elan SC400 i8254 has nonstandard frequency, but it's not the problem. After system startup, no new threads start and no threads exit, but sum of runtimes of all existing threads is much much less than system uptime and the difference is worse with time. Only one timecounter in system. System uptime is correct and respons to time measured by my watch. Svata ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CONF class of files
On 19 June 2011 10:14, Henrik Brix Andersen b...@freebsd.org wrote:
On Jun 19, 2011, at 10:50, Chris Rees wrote:
On 19 June 2011 09:15, Henrik Brix Andersen b...@freebsd.org wrote:
On Jun 17, 2011, at 18:40, Chris Rees wrote:
Macros are being tested for bsd.port.mk that use a new class of files,
in the same vein as the BINOWN variables I have introduced CONFOWN,
CONFGRP, CONFMODE and CONFDIR.
Please would someone review and give an opinion on [1]?
Shouldn't $CONFDIR be set to ${PREFIX}/etc/ instead of /etc?
Also, if we define $CONFDIR, we should use it everywhere in bsd.*.mk where
we currently use some form of */etc/* - otherwise we will get a mismatch if
$CONFDIR is changed from the default.
CONFDIR is for base, not ports, just like most other stuff in that
file. Have a look at the other DIR variables.
Gah, I was confused by you initial mail mentioning bsd.port.mk.
Rereading the patch, I think it looks good. I'd love to see this go in before
9.0 as well.
Hey guys,
Now we've had a bit of interest in this PR, can someone please type
the magic words before the freeze?
Chris
http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/157062
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IPI and I/O interrupts
On Wednesday, June 22, 2011 3:59:06 am Sushanth Rai wrote: Hi, I would like to understand little bit about the FreeBSD interrupt handling on x86. When a cpu is processing an IPI, let's say cpu is running IPI_STOP handler, are I/O interrupts like the timer interrupt disabled ? Conversely if the cpu is holding a spinlock, which means it has disabled interrupts, can it process an IPI. My understanding is executing cli instruction disables the maskable interrupts. I was wondering if IPIs are part of that. Yes, IPIs generally are blocked. We do use an NMI IPI when entering the debugger (and possibly during panics), but general IPIs like TLB shootdowns, etc. are all maskable interrupts. Also, all of the IPI handlers (and the lapic timer interrupt) operate like normal device interrupt handlers using interrupt gates (which block interrupts equivalent to cli). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
