Switching to SMM with FreeBSD 6.2 onwards
Hi All,
I'm not quite familiar with FreeBSD, but I want to do the following in 6.2/7.1.
/* Raise IOPL to 3 to open all I/O ports */
/* something like 'i386_iopl(3)' */
...
/* Open SMRAM access */
outl(unsigned int port, unsigned long int data);
Also, I appreciate comments on the following wrapper:
static inline outl(unsigned int port, unsigned long int data)
{
asm(outl %0, %1 : : a (data), dN (port));
}
My goal is to switch the processor to SMM by triggering SMI from userland.
Thanks in advance,
Won
___
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: Switching to SMM with FreeBSD 6.2 onwards
In message 17314.10813...@web45811.mail.sp1.yahoo.com, Won De Erick wrote:
Hi All,
I'm not quite familiar with FreeBSD, but I want to do the following in 6.2/7.1
.
/* Raise IOPL to 3 to open all I/O ports */
/* something like 'i386_iopl(3)' */
...
see i386_get_ioperm(2) or io(4).
/* Open SMRAM access */
outl(unsigned int port, unsigned long int data);
Also, I appreciate comments on the following wrapper:
static inline outl(unsigned int port, unsigned long int data)
{
asm(outl %0, %1 : : a (data), dN (port));
}
My goal is to switch the processor to SMM by triggering SMI from userland.
Probably this will work.
So what do you want ask about that?
___
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: Switching to SMM with FreeBSD 6.2 onwards
Takanori Watanabe wrote:
In message 17314.10813...@web45811.mail.sp1.yahoo.com, Won De Erick wrote:
Hi All,
I'm not quite familiar with FreeBSD, but I want to do the following in
6.2/7.1
.
/* Raise IOPL to 3 to open all I/O ports */
/* something like 'i386_iopl(3)' */
...
see i386_get_ioperm(2) or io(4).
/* Open SMRAM access */
outl(unsigned int port, unsigned long int data);
Also, I appreciate comments on the following wrapper:
static inline outl(unsigned int port, unsigned long int data)
{
asm(outl %0, %1 : : a (data), dN (port));
}
My goal is to switch the processor to SMM by triggering SMI from userland.
Probably this will work.
So what do you want ask about that?
One thing that comes to my mind is this:
http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf
:)
signature.asc
Description: OpenPGP digital signature
doing 'make installworld / installkernel' a second time?
Hello, I've created a bootable USB key with -CURRENT like this: # mkdir -p /usr/src/CURRENT/obj # cd /usr/src/CURRENT # setenv CVSROOT :pserver:anon...@anoncvs.fr.freebsd.org:/home/ncvs # cvs login # cvs checkout src # cd /usr/src/CURRENT/src # setenv MAKEOBJDIRPREFIX /usr/src/CURRENT/obj # make buildworld # make buildkernel KERNCONF=GENERIC (USB key inserted as /dev/da0) # fdisk -I da0 # fdisk -B da0 # bsdlabel -w da0s1 auto # bsdlabel -B da0s1 # newfs /dev/da0s1a # mount /dev/da0s1a /mnt # make installworld DESTDIR=/mnt # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t # make distrib-dirs DESTDIR=/mnt # make distribution DESTDIR=/mnt # echo /dev/da0s1a / ufs rw 1 1 /mnt/etc/fstab # cat EOF-EOF-EOF /mnt/etc/rc.conf wlans_ath0=wlan0 ifconfig_wlan0=WPA DHCP hostname=tinyCurrent sshd_enable=YES EOF-EOF-EOF # cp /etc/wpa_supplicant.conf /mnt/etc # umount /mnt the resulting USB key boots fine; what I'm unsure about is: can I copy /usr/src/CURRENT onto the key with # cp -rp /usr/src/CURRENT /mnt and when it is booted (in my EeePC) can I do there the installation to the SSD again with # newfs -m 0 -o space /dev/ad2s1a # mount /dev/ad2s1a /mnt # setenv MAKEOBJDIRPREFIX /CURRENT/obj # cd /CURRENT/src # make installworld DESTDIR=/mnt # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t # make distrib-dirs DESTDIR=/mnt # make distribution DESTDIR=/mnt or is /CURRENT/src and /CURRENT/obj not enough for the 2nd installation, for example because the 1st 'make installworld' has removed stuff below /usr/src/CURRENT/obj? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e matthias.ap...@oclc.org - w http://www.oclc.org/ http://www.UnixArea.de/ ___ 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: Switching to SMM with FreeBSD 6.2 onwards
on 27/03/2009 12:35 Ivan Voras said the following:
Takanori Watanabe wrote:
In message 17314.10813...@web45811.mail.sp1.yahoo.com, Won De Erick wrote:
Hi All,
I'm not quite familiar with FreeBSD, but I want to do the following in
6.2/7.1
.
/* Raise IOPL to 3 to open all I/O ports */
/* something like 'i386_iopl(3)' */
...
see i386_get_ioperm(2) or io(4).
/* Open SMRAM access */
outl(unsigned int port, unsigned long int data);
Also, I appreciate comments on the following wrapper:
static inline outl(unsigned int port, unsigned long int data)
{
asm(outl %0, %1 : : a (data), dN (port));
}
Take a look at machine/cpufunc.h
My goal is to switch the processor to SMM by triggering SMI from userland.
Probably this will work.
So what do you want ask about that?
One thing that comes to my mind is this:
http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf
:)
Yeah, and IDA Pro rocks too :-)
--
Andriy Gapon
___
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: Improving the kernel/i386 timecounter performance (GSoC proposal)
Poul-Henning,
Thanks for the feedback!
[...] these must provide a monotonic timescale when queried interleaved
? Be aware that the TSC may not be, and may not stay synchronized across
multiple cores.
The TSC is documented to be monotonically increasing across all x86
processors that implement it (that I'm aware of). I know that the TSC may
not stay synchronized across multiple cores *in theory*. Practically, across
most processors the only real issue has been an offset in the tsc of cores
relative to each other (which can be measured and accounted for), or one
core losing some ticks wrt the other during specific sleep states (this can
be disabled and is recommended by AMD and Red Hat Linux).
Further more, the TSC is not constant frequency and in particular not
known frequency at all times.
The TSC is guaranteed to be constant frequency on relatively modern
processors from Intel and AMD — whether the processor we are running on
supports constant TSC rate can be queried via a CPUID instruction. The
frequency can be measured at boot time by using another timing source such
as the PIT, or read directly off the CPU for some models.
There are a lot of nasty cases to check,
I have implemented many such 'nasty checks' over the past several months
during my work with the xnu kernel — I might have missed some, however. They
are all done once during system boot (and during resume from sleep on some
AMD dual cores). They're not very involved in my opinion.
and a nasty interpolation required,
Could you please elaborate or hint me on some terms I can google about the
interpolations that are required? Are you referring to the interpolation
needed during measuring the tsc frequency to account for the (weird)
duration of PIT? This happens during bootup only.
which, in my tests some years back, totally negated any speedup from using
the TSC in the first place.
This could be an issue: I have not made extensive benchmarks. The benefit of
using TSC could still be: the availability of a higher resolution timer
which can be accessed from userspace.
At the very minimum, you will have to add a quirk table where known good
{CPU+MOBO+BIOS} combinations can be entered, as we find them.
Perhaps. Or alternatively, a quirk table for known *bad* combinations. In my
experience, most current x86 processors are OK (tested on Intel Pentium 4
and above, and AMD Athlons and above, with a variety of motherboard/BIOSes).
Rubbish. Timecounters are not even closely associated with the tick or
ticklessness of the kernel.
My understanding could be flawed here, but the reasoning was: for a tickles
kernel, we need some sort of monotonically increasing, known-rate counter as
a replacement for periodic timer interrupts. Using the TSC (or HPET) would
allow us to do so. Unless the alternative is to read the RTC at each call of
gettimeofday() et al, which itself is not foolproof (eg. the user updates
the hardware clock on a running system). I'm not aware of other
high-resolution counters on the x86 platform which can serve this purpose.
The PIT could be read, but it has too little range (16 bits iirc?) to be
useful unless proper wraparound is done. The TSC is 64bits wide and
guaranteed not to wrap around for 10 years or more (cf. Intel manuals).
the bios may autonomously change the cpu speed
True. This could be an issue. For XNU and the SpeedStep driver we made, we
combat this by disabling such BIOS-initiated frequency changes (refer:
VoodooPower www.superhai.com/darwin.html )
not knowing exactly _when_ and _how_ the cpu clock changed, is a
significant number of microseconds, plenty of time to make strange things
happen.
Yes, for BIOS-initiated cpu frequency changes. For cpufreq driver-initiated
changes, as I mentioned, the kernel can be notified before and after each
change, the duration can be timed using an external timer and accounted for.
You will want to study carefully Dave Mills work to tame the alpha chips
wandering SAW clocks.
Will do. I just started reading your paper on timecounters in FreeBSD which
has been quite informative!
Best,
Prashant Vaibhav
On Fri, Mar 27, 2009 at 3:00 AM, Poul-Henning Kamp p...@phk.freebsd.dkwrote:
In message 17560ccf0903260551v1f5cba9eu87727c0bae7b...@mail.gmail.com,
Prasha
nt Vaibhav writes:
The gettimeofday() function's implementation will then be
changed to read the timestamp counter (TSC) from the processor, and use
the
reading in conjunction with the timing info exported by the kernel to
calculate and return the time info in proper format.
I take it as read, that you know that there are other relvant
functions than gettimeofday() and that these must provide a
monotonic timescale when queried interleaved ?
Be aware that the TSC may not be, and may not stay synchronized
across multiple cores.
Further more, the TSC is not constant frequency and in particular
not known frequency at all times.
There are a lot of nasty cases to check, and a nasty
Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
In message 17560ccf0903270555oe7d1652p7414a221aa2d6...@mail.gmail.com,
Prashant Vaibhav writes:
[...] these must provide a monotonic timescale when queried interleaved
? Be aware that the TSC may not be, and may not stay synchronized across
multiple cores.
The TSC is documented to be monotonically increasing [...]
Notice the absence of the word regular ?
That it is monotonically increasing just means that it does not
count backwards (except on the buggy cpu-revs where it does). It
does not mean that it counts upwards at a stable or constant rate.
Further more, the TSC is not constant frequency and in particular not
known frequency at all times.
The TSC is guaranteed to be constant frequency on relatively modern
processors from Intel and AMD [...]
Which is why you will neeed a {CPU+MOBO+BIOS} table of known good
combinations: the majority of systems out there does not guarantee
and some of those that do lie. Or have bugs. Or both.
There are a lot of nasty cases to check,
They're not very involved in my opinion.
Then you likely have not done enough :-)
and a nasty interpolation required,
Could you please elaborate or hint me on some terms I can google about the
interpolations that are required? Are you referring to the interpolation
needed during measuring the tsc frequency to account for the (weird)
duration of PIT? This happens during bootup only.
I'm talking about the systems where SMM bios operations cause the different
CPU's TSC to develop skew over time.
which, in my tests some years back, totally negated any speedup from using
the TSC in the first place.
This could be an issue: I have not made extensive benchmarks. The benefit of
using TSC could still be: the availability of a higher resolution timer
which can be accessed from userspace.
We have the same resolution today, if you dare to enable TSC in the kernel.
In fact, we have even better resolution, because the struct bintime format
is much more precise than both timespec and timeval. So far I doubt anybody
but me have tried to measure that this makes a difference :-)
At the very minimum, you will have to add a quirk table where known good
{CPU+MOBO+BIOS} combinations can be entered, as we find them.
Perhaps.
Or alternatively, a quirk table for known *bad* combinations.
No, FreeBSD is shipped working by default, not possibly working by
default and particularly not in an area, where the signs of trouble are
so subtle that most people don't recognize them at all and just blame
it on random buggy crap.
Rubbish. Timecounters are not even closely associated with the tick or
My understanding could be flawed here, but the reasoning was: for a tickles
kernel, we need some sort of monotonically increasing, known-rate counter as
a replacement for periodic timer interrupts.
We already have that in FreeBSD for CPU time accounting.
The crucial fact about a tickless kernel, is that it does not take an
interrupt N times a second just to see if there is anything to do in the
callout queue, but instead uses the hardware timer to aim an interrupt
at the next time it needs to wake up.
the bios may autonomously change the cpu speed
True. This could be an issue.
Your optimism is cute but misguided.
On most laptops the bios WILL change the CPU speed without notice
in reaction to temperature and battery power.
Let me repeat:
[1] In my mind, reworking the callout system in the kernel would
be a much better more neded and much more worthwhile project.
Poul-Henning
--
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-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: Switching to SMM with FreeBSD 6.2 onwards
--- On Fri, 3/27/09, Andriy Gapon a...@icyb.net.ua wrote:
on 27/03/2009 12:35 Ivan Voras said
the following:
Takanori Watanabe wrote:
In message 17314.10813...@web45811.mail.sp1.yahoo.com,
Won De Erick wrote:
Hi All,
I'm not quite familiar with FreeBSD, but I
want to do the following in 6.2/7.1
.
/* Raise IOPL to 3 to open all I/O ports
*/
/* something like 'i386_iopl(3)' */
...
see i386_get_ioperm(2) or io(4).
/* Open SMRAM access */
outl(unsigned int port, unsigned long
int data);
Also, I appreciate comments on the following
wrapper:
static inline outl(unsigned int port, unsigned
long int data)
{
asm(outl %0, %1 : : a (data), dN
(port));
}
Take a look at machine/cpufunc.h
Oh I see. :)
My goal is to switch the processor to SMM by
triggering SMI from userland.
Probably this will work.
So what do you want ask about that?
If it is possible, I should want to write data to certain registers or portion
of a memory where the BIOS firmware or the BMC firmware could possibly detect
it as 'reconfiguration', and make significant log on SEL as System
Reconfigured. If someone has a better idea, it is very much welcome.
One thing that comes to my mind is this:
http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf
I will add that to the ff:
http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf
I've made the Exploit code found at the appendix runnable on FreeBSD 7.1
replacing some of the unsupported functions, but I'm still finding ways how to
verify whether I've written successfully a data to the intended address or not.
I've replaced '/dev/xf86 with '/dev/mem'. Then opened 'dev/io' instead of using
'i386_get_ioperm()'. Am I on the right track?
:)
Yeah, and IDA Pro rocks too :-)
--
Andriy Gapon
___
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: Switching to SMM with FreeBSD 6.2 onwards
on 27/03/2009 15:47 Won De Erick said the following: --- On Fri, 3/27/09, Andriy Gapon a...@icyb.net.ua wrote: on 27/03/2009 12:35 Ivan Voras said the following: One thing that comes to my mind is this: http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf I will add that to the ff: http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf I've made the Exploit code found at the appendix runnable on FreeBSD 7.1 replacing some of the unsupported functions, but I'm still finding ways how to verify whether I've written successfully a data to the intended address or not. I've replaced '/dev/xf86 with '/dev/mem'. Then opened 'dev/io' instead of using 'i386_get_ioperm()'. Am I on the right track? I believe yes. I made identical changes to Joanna/Rafal's code that gets a glimpse of what SMI handler does via CPU cache. Interesting read :) -- Andriy Gapon ___ 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: Switching to SMM with FreeBSD 6.2 onwards
--- On Fri, 3/27/09, Andriy Gapon a...@icyb.net.ua wrote: on 27/03/2009 15:47 Won De Erick said the following: --- On Fri, 3/27/09, Andriy Gapon a...@icyb.net.ua wrote: on 27/03/2009 12:35 Ivan Voras said the following: One thing that comes to my mind is this: http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf I will add that to the ff: http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf I've made the Exploit code found at the appendix runnable on FreeBSD 7.1 replacing some of the unsupported functions, but I'm still finding ways how to verify whether I've written successfully a data to the intended address or not. I've replaced '/dev/xf86 with '/dev/mem'. Then opened 'dev/io' instead of using 'i386_get_ioperm()'. Am I on the right track? I believe yes. I made identical changes to Joanna/Rafal's code that gets a glimpse of what SMI handler does via CPU cache. Interesting read :) Have you tried modifying some chipset configurations? Can I know what part? I am using IBM x3650 with dual core Xeon processor. -- Andriy Gapon Hi all, is there any tool that I can use to view the memory map I/O? ___ 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
CURRENT sees only /dev/ad2s1a, but not /dev/ad3s1a
Hello, When I boot my EeePC from USB key (/dev/da0s1a) -CURRENT it sees the two SSD only as $ ls -l /dev/ad* /dev/ad2 /dev/ad2s1 /dev/ad2s1a /dev/ad3 /dev/ad3a I can mount /dev/ad2s1a but ofc not /dev/ad3s1a; when I'm booting the RELENG_7 from /dev/ad2s1a itself it looks like this: $ mount /dev/ad2s1a on / (ufs, local, noatime) /dev/ad3s1a on /usr/home (ufs, local, noatime) ... and all runs fine; more details below... What could be the reason for this? Thx matthias $ uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 r...@rebelion.sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 $ ls -l /dev/ad* crw-r- 1 root operator0, 79 Mar 27 15:45 /dev/ad2 crw-r- 1 root operator0, 80 Mar 27 15:45 /dev/ad2s1 crw-r- 1 root operator0, 81 Mar 27 15:45 /dev/ad2s1a crw-r- 1 root operator0, 83 Mar 27 15:45 /dev/ad3 crw-r- 1 root operator0, 84 Mar 27 15:45 /dev/ad3a $ mount /dev/da0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad2s1a on /mnt (ufs, local, read-only) $ dmesg Copyright (c) 1992-2009 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 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 r...@rebelion.sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 900MHz (900.10-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6d8 Stepping = 8 Features=0xafe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE AMD Features=0x10NX real memory = 1064828928 (1015 MB) avail memory = 1024409600 (976 MB) ACPI APIC Table: A M I OEMAPIC ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: A M I OEMRSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3f70 (3) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0x18 port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xec00-0xec07 mem 0xf7f0-0xf7f7,0xd000-0xdfff,0xf7ec-0xf7ef irq 16 at device 2.0 on pci0 agp0: Intel 82915GM (915GM GMCH) SVGA controller on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: VGA-compatible display mem 0xf7f8-0xf7ff at device 2.1 on pci0 pci0: multimedia, HDA at device 27.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci3: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 18 at device 28.2 on pci0 pci1: ACPI PCI bus on pcib2 uhci0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0xe400-0xe41f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f30 usbus0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0xe480-0xe49f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f30 usbus1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B on uhci1 uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0xe800-0xe81f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f30 usbus2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C on uhci2 uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0xe880-0xe89f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0f30 usbus3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D on uhci3 ehci0: Intel 82801FB (ICH6) USB 2.0 controller mem 0xf7eb7c00-0xf7eb7fff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: Intel 82801FB (ICH6) USB 2.0 controller on ehci0 pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib3 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH6M SATA150 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 acpi_button1: Power Button on acpi0 acpi_tz0: Thermal Zone on acpi0 battery0: ACPI Control Method Battery on acpi0 acpi_acad0: AC Adapter on acpi0 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0
Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
Prashant Vaibhav wrote: The primary idea is to improve the performance and resolution of gettimeofday() and friends by creating a efficient userspace implementation of these functions, along with some supporting modifications to the kernel. Are you aware of CLOCK_*_FAST family of timecounters present in FreeBSD 7.x? If not, you may want to take a look: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/time.h#rev1.71 Eugene Grosbein ___ 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: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
(Sorry for the top quoting). Probably the best implementation of
gettimeofd= ay() is to have
a page in the kernel mapped read-only to all the user pr= ocesses. Put
the kernel's idea of time
into this page. Then getting the = time becomes a simple read (OK, two
reads, to make sure that
no update = has happened in between).
The TSC can then be used to add the precis= ion between the ticks of
the kernel timer:
i.e. remember the value of TS= C when the last tick happen, and the
highest rate at which
TSC may be ti= cking at this CPU, and export in the same page. This
would guarantee thatthe time is not moving back.
However there are more issues with TS= C. TSC is guaranteed to have
the same value
on all the processors that s= hare the same system bus. But if the
machine is built of multiple
buses = with bridges between them, all bets are off. Each bus may be
stopped, resta= rted
and clocked separately. There is no way to tell, on which CPU is th= e
process currently
runnning, and it may be rescheduled do a different C= PU right before
or after the RDTSC
instruction.
-SB
Ma= r 26, 2009 06:55:04 PM, [1]...@phk.freebsd.dk wrote:
In message [2]17560ccf0903260551v1f5cba9eu8
7727c0bae7b...@mail.gmail.com, Prasha
nt Vaibhav writes:
= The gettimeofday() function's implementation will then be
change= d to read the timestamp counter (TSC) from the processor,
and use the
g= t;reading in conjunction with the timing info exported by the
kernel to
= calculate and return the time info in proper format.
I take it a= s read, that you know that there are other relvant
functions than gettim= eofday() and that these must provide a
monotonic timescale when queried = interleaved ?
Be aware that the TSC may not be, and may not stay syn= chronized
across multiple cores.
Further more, the TSC is not con= stant frequency and in particular
not known frequency at all times.
There are a lot of nasty cases to check, and a nasty interpolation
= required, which, in my tests some years back, totally negated any
speedu= p from using the TSC in the first place.
At the very minimum, you wi= ll have to add a quirk table where
known good {CPU+MOBO+BIOS} combinatio= ns can be entered, as we
find them.
This will also pave way f= or optionally making the
FreeBSD kernel tickless,
Rubbish. T= imecounters are not even closely associated with the
tick or ticklessnes= s of the kernel. [1]
- The TSC frequency might change on cert= ain processors with
non-constant
TSC rate (because of SpeedStep, = dynamic freq scaling etc.). The
only way to
combat this is that t= he kernel be notified every time the
processor
frequency changes.= Every cpu frequency driver will need to be
updated to
notify the= kernel before and after a cpu freq change.
That is not good enough= , the bios may autonomously change the cpu
speed
and the skew from not k= nowing exactly _when_ and _how_ the cpu
clock
changed, is a significant = number of microseconds, plenty of time
to make strange things happen.
You will want to study carefully Dave Mills work to tame the alpha
= chips wandering SAW clocks.
Poul-Henning
[1] In my mind, rewo= rking the callout system in the kernel would
be a much better more neded= and much more worthwhile project.
--
Poul-Henning Kamp | = UNIX since Zilog Zeus 3.20
[3]...@freebsd.org | TCP= /IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
N= ever attribute to malice what can adequately be explained by
incompetence.= br___
[4]freebsd-hack...@freebsd.org mailing list
[5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo
unsubscribe, send any mail to [6]fre
ebsd-hackers-unsubscr...@freebsd.org
References
1. 3Dmailto:p...@phk.freebsd.dk;
2. file://localhost/tmp/3D 3. 3Dmailto:p...@freebsd.org;
4. 3Dmailto:fre 5. 3Dhttp://lists.=/
6.
3Dmailto:freebsd-hackers-unsub___
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: amr driver broken since March 12
Danny Braniss wrote: at least for me :-) [and sorry for the cross posting] old (March 12 , i know need the svn rev number but...) None of the commit activity on March 12 is jumping out at me as being suspicious. However, you are now the second person who has told me about AMR problems in 7.1 recently. If you have a precise svn change number, it would help greatly. Scott my bad. the last working amr/iir is from March 12. I first detected the problem sometime later, but not later than March 23. So it has to be changes in that time frame. both drivers are showing similar symptoms: waiting for not busy the iir goes on for ever, and it's the cam that eventually panics, run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config (actually not 100% true, depending if WITNESS is on or off, it sometimes just hangs). the amr seems to time out: amr0: adapter is busy thanks for looking into the problem, danny ___ 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: amr driver broken since March 12
On Fri, Mar 27, 2009 at 06:52:32PM +0300, Danny Braniss wrote: Danny Braniss wrote: at least for me :-) [and sorry for the cross posting] old (March 12 , i know need the svn rev number but...) None of the commit activity on March 12 is jumping out at me as being suspicious. However, you are now the second person who has told me about AMR problems in 7.1 recently. If you have a precise svn change number, it would help greatly. Scott (Long) my bad. the last working amr/iir is from March 12. I first detected the problem sometime later, but not later than March 23. So it has to be changes in that time frame. I think Scott Long was actually asking if you could try to cvsup (or csup) to a date between those two and see if the problem shows there. If you go for, (23 - 12/2) + 12, something like March 17, it would help to narrow what changes could be causing the problem. If you see the problem with a March 17 kernel, you can split the time between March 12 and 17 and try again. Then just keep cutting the search space in half until you can pretty much say This is the commit that broke things for me. It's not always possible for someone to take the time to do the binary search for the actual commit which broke things for them. But when they can, it really helps the developers. Just cutting it down from 11 days to 5 or 6 days can probably be a big help. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org ___ 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: amr driver broken since March 12
Danny Braniss wrote: Danny Braniss wrote: at least for me :-) [and sorry for the cross posting] old (March 12 , i know need the svn rev number but...) None of the commit activity on March 12 is jumping out at me as being suspicious. However, you are now the second person who has told me about AMR problems in 7.1 recently. If you have a precise svn change number, it would help greatly. Scott my bad. the last working amr/iir is from March 12. I first detected the problem sometime later, but not later than March 23. So it has to be changes in that time frame. both drivers are showing similar symptoms: waiting for not busy the iir goes on for ever, and it's the cam that eventually panics, run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config (actually not 100% true, depending if WITNESS is on or off, it sometimes just hangs). the amr seems to time out: amr0: adapter is busy thanks for looking into the problem, danny Ok, here are a series of revisions to step through, in forward order. Make sure that you are starting with at least revision 189568. Then, update to exactly the revision numbers below, recompile the kernel, and test: 190087 190091 ___ 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: CURRENT sees only /dev/ad2s1a, but not /dev/ad3s1a
On 3/27/09, Matthias Apitz g...@unixarea.de wrote: Hello, When I boot my EeePC from USB key (/dev/da0s1a) -CURRENT it sees the two SSD only as $ ls -l /dev/ad* /dev/ad2 /dev/ad2s1 /dev/ad2s1a /dev/ad3 /dev/ad3a I can mount /dev/ad2s1a but ofc not /dev/ad3s1a; when I'm booting the RELENG_7 from /dev/ad2s1a itself it looks like this: $ mount /dev/ad2s1a on / (ufs, local, noatime) /dev/ad3s1a on /usr/home (ufs, local, noatime) CURRENT have replaced geom_bsd with geom_part_bsd and that can cause various problems, search current archives for more info. -- Paul ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
I've been talking about this for years. All I need is help with the VM
magic to create the page on fork. I also want two pages, one global
for gettimeofday (and any other global data we can think of) and one
per-process for static data like getpid/getgid.
Scott
Sergey Babkin wrote:
(Sorry for the top quoting). Probably the best implementation of
gettimeofd=y() is to have
a page in the kernel mapped read-only to all the user pr=cesses. Put
the kernel's idea of time
into this page. Then getting the =ime becomes a simple read (OK, two
reads, to make sure that
no update =as happened in between).
The TSC can then be used to add the precis=on between the ticks of
the kernel timer:
i.e. remember the value of TS= when the last tick happen, and the
highest rate at which
TSC may be ti=king at this CPU, and export in the same page. This
would guarantee thatthe time is not moving back.
However there are more issues with TS=. TSC is guaranteed to have
the same value
on all the processors that s=are the same system bus. But if the
machine is built of multiple
buses =ith bridges between them, all bets are off. Each bus may be
stopped, resta=ted
and clocked separately. There is no way to tell, on which CPU is th=
process currently
runnning, and it may be rescheduled do a different C=U right before
or after the RDTSC
instruction.
-SB
Ma= 26, 2009 06:55:04 PM, [1]...@phk.freebsd.dk wrote:
In message [2]17560ccf0903260551v1f5cba9eu8 7727c0bae7b...@mail.gmail.com, Prasha
nt Vaibhav writes:
=The gettimeofday() function's implementation will then be
change= to read the timestamp counter (TSC) from the processor,
and use the
g=;reading in conjunction with the timing info exported by the
kernel to
=calculate and return the time info in proper format.
I take it a= read, that you know that there are other relvant
functions than gettim=ofday() and that these must provide a
monotonic timescale when queried =nterleaved ?
Be aware that the TSC may not be, and may not stay syn=hronized
across multiple cores.
Further more, the TSC is not con=tant frequency and in particular
not known frequency at all times.
There are a lot of nasty cases to check, and a nasty interpolation
=equired, which, in my tests some years back, totally negated any
speedu= from using the TSC in the first place.
At the very minimum, you wi=l have to add a quirk table where
known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we
find them.
This will also pave way f=r optionally making the
FreeBSD kernel tickless,
Rubbish. T=mecounters are not even closely associated with the
tick or ticklessnes= of the kernel. [1]
- The TSC frequency might change on cert=in processors with
non-constant
TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The
only way to
combat this is that t=e kernel be notified every time the
processor
frequency changes.=very cpu frequency driver will need to be
updated to
notify the=ernel before and after a cpu freq change.
That is not good enough= the bios may autonomously change the cpu
speed
and the skew from not k=owing exactly _when_ and _how_ the cpu
clock
changed, is a significant =umber of microseconds, plenty of time
to make strange things happen.
You will want to study carefully Dave Mills work to tame the alpha
=hips wandering SAW clocks.
Poul-Henning
[1] In my mind, rewo=king the callout system in the kernel would
be a much better more neded=nd much more worthwhile project.
--
Poul-Henning Kamp | =NIX since Zilog Zeus 3.20
[3]...@freebsd.org | TCP=IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
N=ver attribute to malice what can adequately be explained by
incompetence.=r___
[4]freebsd-hack...@freebsd.org mailing list
[5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo
unsubscribe, send any mail to [6]fre
ebsd-hackers-unsubscr...@freebsd.org
References
1. 3Dmailto:p...@phk.freebsd.dk;
2. file://localhost/tmp/3D 3. 3Dmailto:p...@freebsd.org;
4. 3Dmailto:fre 5. 3Dhttp://lists.=/
6.
3Dmailto:freebsd-hackers-unsub___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
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: Improving the kernel/i386 timecounter performance (GSoC proposal)
In message 49cd0405.1060...@samsco.org, Scott Long writes: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. Agreed, that is a good place to start. -- 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-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: Improving the kernel/i386 timecounter performance (GSoC proposal)
On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 49cd0405.1060...@samsco.org, Scott Long writes: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. Agreed, that is a good place to start. I'm assuming folks are still in love with the TSC because it still the cheapest as oppose ACPI-fast or HPET to even contemplate this? Also I thought at least PHK's comment (Sergey mentioned it) was true regardless of bus, that the TSC is not consistent across multiple packages (and for that matter I suppose cores) due to I *think* its ISA lineage so how does this work again? Won't the rate in which you tick up be sporadic over the course of the process scheduled on different cores? (i.e. depending on what core RDTSC happened to land on) -aps ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
On Fri, 27 Mar 2009, Scott Long wrote:
I've been talking about this for years. All I need is help with the VM
magic to create the page on fork. I also want two pages, one global for
gettimeofday (and any other global data we can think of) and one per-process
for static data like getpid/getgid.
FWIW, there are some variations in schemes across OS's -- one extreme is the
Linux approach, which actually exports a mini shared library in ELF format on
the shared page, providing implementations of various services (such as
entering system calls), time stuff, etc. Less extreme are the shared pages
offered on Mac OS X, etc.
Robert N M Watson
Computer Laboratory
University of Cambridge
Scott
Sergey Babkin wrote:
(Sorry for the top quoting). Probably the best implementation of
gettimeofd=y() is to have
a page in the kernel mapped read-only to all the user pr=cesses. Put
the kernel's idea of time
into this page. Then getting the =ime becomes a simple read (OK, two
reads, to make sure that
no update =as happened in between).
The TSC can then be used to add the precis=on between the ticks of
the kernel timer:
i.e. remember the value of TS= when the last tick happen, and the
highest rate at which
TSC may be ti=king at this CPU, and export in the same page. This
would guarantee thatthe time is not moving back.
However there are more issues with TS=. TSC is guaranteed to have
the same value
on all the processors that s=are the same system bus. But if the
machine is built of multiple
buses =ith bridges between them, all bets are off. Each bus may be
stopped, resta=ted
and clocked separately. There is no way to tell, on which CPU is th=
process currently
runnning, and it may be rescheduled do a different C=U right before
or after the RDTSC
instruction.
-SB
Ma= 26, 2009 06:55:04 PM, [1]...@phk.freebsd.dk wrote:
In message [2]17560ccf0903260551v1f5cba9eu8
7727c0bae7b...@mail.gmail.com, Prasha
nt Vaibhav writes:
=The gettimeofday() function's implementation will then be
change= to read the timestamp counter (TSC) from the processor,
and use the
g=;reading in conjunction with the timing info exported by the
kernel to
=calculate and return the time info in proper format.
I take it a= read, that you know that there are other relvant
functions than gettim=ofday() and that these must provide a
monotonic timescale when queried =nterleaved ?
Be aware that the TSC may not be, and may not stay syn=hronized
across multiple cores.
Further more, the TSC is not con=tant frequency and in particular
not known frequency at all times.
There are a lot of nasty cases to check, and a nasty interpolation
=equired, which, in my tests some years back, totally negated any
speedu= from using the TSC in the first place.
At the very minimum, you wi=l have to add a quirk table where
known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we
find them.
This will also pave way f=r optionally making the
FreeBSD kernel tickless,
Rubbish. T=mecounters are not even closely associated with the
tick or ticklessnes= of the kernel. [1]
- The TSC frequency might change on cert=in processors with
non-constant
TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The
only way to
combat this is that t=e kernel be notified every time the
processor
frequency changes.=very cpu frequency driver will need to be
updated to
notify the=ernel before and after a cpu freq change.
That is not good enough= the bios may autonomously change the cpu
speed
and the skew from not k=owing exactly _when_ and _how_ the cpu
clock
changed, is a significant =umber of microseconds, plenty of time
to make strange things happen.
You will want to study carefully Dave Mills work to tame the alpha
=hips wandering SAW clocks.
Poul-Henning
[1] In my mind, rewo=king the callout system in the kernel would
be a much better more neded=nd much more worthwhile project.
--
Poul-Henning Kamp | =NIX since Zilog Zeus 3.20
[3]...@freebsd.org | TCP=IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
N=ver attribute to malice what can adequately be explained by
incompetence.=r___
[4]freebsd-hack...@freebsd.org mailing list
[5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo
unsubscribe, send any mail to [6]fre
ebsd-hackers-unsubscr...@freebsd.org
References
1. 3Dmailto:p...@phk.freebsd.dk;
2. file://localhost/tmp/3D 3. 3Dmailto:p...@freebsd.org;
4. 3Dmailto:fre 5. 3Dhttp://lists.=/
6.
3Dmailto:freebsd-hackers-unsub___
freebsd-curr...@freebsd.org mailing list
Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
On Fri, 27 Mar 2009, Scott Long wrote:
I've been talking about this for years. All I need is help with the VM
magic to create the page on fork. I also want two pages, one global for
gettimeofday (and any other global data we can think of) and one per-process
for static data like getpid/getgid.
One note though -- the time to do the global page is at execve()-time.
Robert N M Watson
Computer Laboratory
University of Cambridge
Scott
Sergey Babkin wrote:
(Sorry for the top quoting). Probably the best implementation of
gettimeofd=y() is to have
a page in the kernel mapped read-only to all the user pr=cesses. Put
the kernel's idea of time
into this page. Then getting the =ime becomes a simple read (OK, two
reads, to make sure that
no update =as happened in between).
The TSC can then be used to add the precis=on between the ticks of
the kernel timer:
i.e. remember the value of TS= when the last tick happen, and the
highest rate at which
TSC may be ti=king at this CPU, and export in the same page. This
would guarantee thatthe time is not moving back.
However there are more issues with TS=. TSC is guaranteed to have
the same value
on all the processors that s=are the same system bus. But if the
machine is built of multiple
buses =ith bridges between them, all bets are off. Each bus may be
stopped, resta=ted
and clocked separately. There is no way to tell, on which CPU is th=
process currently
runnning, and it may be rescheduled do a different C=U right before
or after the RDTSC
instruction.
-SB
Ma= 26, 2009 06:55:04 PM, [1]...@phk.freebsd.dk wrote:
In message [2]17560ccf0903260551v1f5cba9eu8
7727c0bae7b...@mail.gmail.com, Prasha
nt Vaibhav writes:
=The gettimeofday() function's implementation will then be
change= to read the timestamp counter (TSC) from the processor,
and use the
g=;reading in conjunction with the timing info exported by the
kernel to
=calculate and return the time info in proper format.
I take it a= read, that you know that there are other relvant
functions than gettim=ofday() and that these must provide a
monotonic timescale when queried =nterleaved ?
Be aware that the TSC may not be, and may not stay syn=hronized
across multiple cores.
Further more, the TSC is not con=tant frequency and in particular
not known frequency at all times.
There are a lot of nasty cases to check, and a nasty interpolation
=equired, which, in my tests some years back, totally negated any
speedu= from using the TSC in the first place.
At the very minimum, you wi=l have to add a quirk table where
known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we
find them.
This will also pave way f=r optionally making the
FreeBSD kernel tickless,
Rubbish. T=mecounters are not even closely associated with the
tick or ticklessnes= of the kernel. [1]
- The TSC frequency might change on cert=in processors with
non-constant
TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The
only way to
combat this is that t=e kernel be notified every time the
processor
frequency changes.=very cpu frequency driver will need to be
updated to
notify the=ernel before and after a cpu freq change.
That is not good enough= the bios may autonomously change the cpu
speed
and the skew from not k=owing exactly _when_ and _how_ the cpu
clock
changed, is a significant =umber of microseconds, plenty of time
to make strange things happen.
You will want to study carefully Dave Mills work to tame the alpha
=hips wandering SAW clocks.
Poul-Henning
[1] In my mind, rewo=king the callout system in the kernel would
be a much better more neded=nd much more worthwhile project.
--
Poul-Henning Kamp | =NIX since Zilog Zeus 3.20
[3]...@freebsd.org | TCP=IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
N=ver attribute to malice what can adequately be explained by
incompetence.=r___
[4]freebsd-hack...@freebsd.org mailing list
[5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo
unsubscribe, send any mail to [6]fre
ebsd-hackers-unsubscr...@freebsd.org
References
1. 3Dmailto:p...@phk.freebsd.dk;
2. file://localhost/tmp/3D 3. 3Dmailto:p...@freebsd.org;
4. 3Dmailto:fre 5. 3Dhttp://lists.=/
6.
3Dmailto:freebsd-hackers-unsub___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
Robert Watson wrote: On Fri, 27 Mar 2009, Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. FWIW, there are some variations in schemes across OS's -- one extreme is the Linux approach, which actually exports a mini shared library in ELF format on the shared page, providing implementations of various services (such as entering system calls), time stuff, etc. Less extreme are the shared pages offered on Mac OS X, etc. Yes, but I'd like to start somewhere, and considering that it's been impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB time to get the basic VM magic done, I'm keeping my expectations as modest as possible. Scott ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
Scott Long wrote: Robert Watson wrote: On Fri, 27 Mar 2009, Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. FWIW, there are some variations in schemes across OS's -- one extreme is the Linux approach, which actually exports a mini shared library in ELF format on the shared page, providing implementations of various services (such as entering system calls), time stuff, etc. Less extreme are the shared pages offered on Mac OS X, etc. Yes, but I'd like to start somewhere, and considering that it's been impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB time to get the basic VM magic done, I'm keeping my expectations as modest as possible. try alc.. :-) Scott ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. interestingly it is even feasible to have a per-thread page.. it requires that the scheduler change a page table entry tough. ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
Hi, Scott all-- On Mar 27, 2009, at 11:30 AM, Scott Long wrote: Robert Watson wrote: On Fri, 27 Mar 2009, Scott Long wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. FWIW, there are some variations in schemes across OS's -- one extreme is the Linux approach, which actually exports a mini shared library in ELF format on the shared page, providing implementations of various services (such as entering system calls), time stuff, etc. Less extreme are the shared pages offered on Mac OS X, etc. Yes, but I'd like to start somewhere, and considering that it's been impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB time to get the basic VM magic done, I'm keeping my expectations as modest as possible. I'm not entirely sure how close the Mach/xnu and FreeBSD implementations of pmap_* stuff are, but the xnu code for commpage stuff is here: http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/pmap.c [pmap_commpage32_init(), pmap_commpage64_init()] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/commpage/ [all :-)] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/commpage/commpage_gettimeofday.s [but this one in particular] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/vm/vm_shared_region.c [cf COMM PAGE comments, vm_commpage_init()] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/bsd/kern/kern_fork.c [fork_create_child(), procdup(), uses of pmap_map_sharedpage()] [ ADC login might be needed, otherwise I think rwatson has been importing xnu periodically for TrustedBSD or other work, and might be able to provide similar pointers... ] Regards, -- -Chuck ___ 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
Building a DDB friendly kernel/drivers?
Hi Folks: I'm debugging an issue with a third-party driver that causes an NMI during driver initialization. It only occurs for one version of the driver thus far. I want to isolate what triggers the NMI and generally get a feel for the initialization of the hardware. I'm running a 6.x-amd64 kernel. Can someone explain to me why when I compile the kernel with default debugging options (makeoptions -g, options DDB/KDB etc. etc.) the kernel comes and boots BUT if I remove -O2 and -frename-registers (in an effort to make text even close to readible), the kernel boots and then double-faults on mounting root? I guess more importantly, what's the RIGHT way to build a DDB/KDB friendly kernel? I thought -O2 and/or -frename-registers could cause DDB to act up but perhaps I'm wrong. Thanks! -aps ___ 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: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
Would not a normal mmap be duplicated on fork? I'd do it as a small pseudo-= driver that allows to mmap this page. Then libc would open this pseudo-d evice and mmap it, either in the on-load handler or on the first call of gettimeofday(). I think, that should be it, no special magic nece= ssary. The per-process is more difficult and would require the magic= :-) Or maybe no magic a s such: just mmap the file from the /proc files= ystem. Then on fork in the child unmap this page, open the new file, and= map it. vfork will still be tricky :-) It also means wasting an extra p= age per process. -SB Mar 27, 2009 12:51:56 PM, [1]sco...@samsc= o.org wrote: I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one gl obal for gettimeofday (and any other global data we can think of) and on= e per-process for static data like getpid/getgid. Scott Sergey Babkin wrote: (Sorry for the top quoting). Probably the= best implementation of gettimeofd=y() is to have a= page in the kernel mapped read-only to all the user pr=cesses. Put g= t; the kernel's idea of time into this page. Then getting the= =ime becomes a simple read (OK, two reads, to make sure that= br no update =as happened in between). References 1. file://localhost/tmp/3Dmai___ 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: Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
On Fri, 27 Mar 2009, Sergey Babkin wrote: Would not a normal mmap be duplicated on fork? I'd do it as a small pseudo-= driver that allows to mmap this page. Then libc would open this pseudo-d= evice and mmap it, either in the on-load handler or on the first call of= gettimeofday(). I think, that should be it, no special magic nece= ssary. The per-process is more difficult and would require the magic= :-) Or maybe no magic a s such: just mmap the file from the /proc files= ystem. Then on fork in the child unmap this page, open the new file, and= map it. vfork will still be tricky :-) It also means wasting an extra p= age per process. Part of the point of mapping in the page at execve()-time, or fork()-time for per-process pages (which I'm not entirely convinced we need yet) is to avoid the cost of an extra device open, mmap, etc, for every execve(), which can be quite expensive. I stuck a prototype page mapped from a special device exporting time information here a year or two ago: http://www.watson.org/~robert/freebsd/20080203-evilmem.diff http://www.watson.org/~robert/freebsd/evilmem_test.c This doesn't do TSC-based adjustment, just drops a timestamp in from the callout wheel, but was intended to allow Kris to do a bit of comparative benchmarking and decide if it might be a viable approach to invest further work in. Obviously, the above code should never, ever, get near a production kernel, since it was a 2-hour hack for experimental purposes. I think the right way forward is to prototype: map the page in at execve()-time in the kernel and pass the address to rtld via elf auxiliary arguments, and have rtld link it (via some or another means), exposing symbols or code or whatever, to libc. If someone wants to make it a dynamic shared object in ELF-speak, then I'm all for that as it would minimize the work rtld had to do. I guess interesting questions are whether (a) it would be desirable to have per-page, per-cpu, or per-thread mappings. If there are non-synchronized TSCs, then there might be some interesting advantages to a per-CPU page. Robert N M Watson Computer Laboratory University of Cambridge -SB Mar 27, 2009 12:51:56 PM, [1]sco...@samsc= o.org wrote: I've been talking about this for years. All I need is help with = the VM magic to create the page on fork. I also want two pages, one gl= obal for gettimeofday (and any other global data we can think of) and on= e per-process for static data like getpid/getgid. Scott Sergey Babkin wrote: (Sorry for the top quoting). Probably the= best implementation of gettimeofd=3Dy() is to have a= page in the kernel mapped read-only to all the user pr=3Dcesses. Put g= t; the kernel's idea of time into this page. Then getting the= =3Dime becomes a simple read (OK, two reads, to make sure that= br no update =3Das happened in between). References 1. file://localhost/tmp/3Dmai= ___ 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 ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
In message alpine.bsf.2.00.0903272254460.12...@fledge.watson.org, Robert Wats on writes: I guess interesting questions are whether (a) it would be desirable to have per-page, per-cpu, or per-thread mappings. If there are non-synchronized TSCs, then there might be some interesting advantages to a per-CPU page. Rule #3: The only thing worse than generalizing from one example is generalizing from no examples at all. We can add those mappings when we know why we would want them. -- 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-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: Improving the kernel/i386 timecounter performance (GSoC proposal)
On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.0903272254460.12...@fledge.watson.org, Robert Wats on writes: I guess interesting questions are whether (a) it would be desirable to have per-page, per-cpu, or per-thread mappings. If there are non-synchronized TSCs, then there might be some interesting advantages to a per-CPU page. Rule #3: The only thing worse than generalizing from one example is generalizing from no examples at all. We can add those mappings when we know why we would want them. If we believe TSCs won't be synchronized, and don't want to synchronize them ourselves, then we'll need different mapping state to get from a TSC stamp to a time on different CPUs. In which case user application threads will need to know their CPU in order to use the right conversion data (ideally without a system call, since that's part of what we're avoiding here), or use a per-CPU mapping and not know (in which case they'll need to detect and handle the very rare preempted and migrated between read TSC and read conversion data race). I'm not pushing a per-CPU page, but there would be some interesting advantages to supporting that. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
In message alpine.bsf.2.00.0903272303040.12...@fledge.watson.org, Robert Wats on writes: In which case user application threads will need to know their CPU [...] Didn't jemalloc solve that problem once already ? -- 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-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: Improving the kernel/i386 timecounter performance (GSoC proposal)
On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.0903272303040.12...@fledge.watson.org, Robert Wats on writes: In which case user application threads will need to know their CPU [...] Didn't jemalloc solve that problem once already ? I think jemalloc implements thread-affinity for arenas rather than CPU-affinity in the strict sense, but I may misread. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
Robert Watson wrote: On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.0903272303040.12...@fledge.watson.org, Robert Wats on writes: In which case user application threads will need to know their CPU [...] Didn't jemalloc solve that problem once already ? I think jemalloc implements thread-affinity for arenas rather than CPU-affinity in the strict sense, but I may misread. CPU affinity is of limited use to malloc unless it can safely pin threads to CPUs. Unfortunately, malloc cannot muck with CPU affinity, since that's up to the application. Therefore, as you say, jemalloc implements (dynamically balanced) arena affinity. It might work okay in practice to use the current CPU ID to decide which arena to use, if the scheduler does not often migrate running processes. I haven't explored that possibility though, since the infrastructure for cheaply querying the CPU ID doesn't currently (to my knowledge) exist. Jason ___ 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
