Re: Extremely slow boot on VMWare with Opteron 2352 (acpi?)
On Tue, Mar 09, 2010 at 06:42:02PM -0600, Kevin Day wrote:
On Mar 9, 2010, at 4:27 PM, John Baldwin wrote:
On Tuesday 09 March 2010 3:40:26 pm Kevin Day wrote:
If I boot up on an Opteron 2218 system, it boots normally. If I boot the
exact same VM moved to a 2352, I get:
acpi0: INTEL 440BX on motherboard
PCIe: Memory Mapped configuration base @ 0xe000
(very long pause)
ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48
acpi0: [MPSAFE]
acpi0: [ITHREAD]
then booting normally.
It's probably worth adding some printfs to narrow down where the pause is
happening. This looks to be all during the acpi_attach() routine, so maybe
you can start there.
Okay, good pointer. This is what I've narrowed down:
acpi_enable_pcie() calls pcie_cfgregopen(). It's called here with
pcie_cfgregopen(0xe000, 0, 255). inside pcie_cfgregopen, the pause starts
here:
/* XXX: We should make sure this really fits into the direct map. */
pcie_base = (vm_offset_t)pmap_mapdev(base, (maxbus + 1) 20);
pmap_mapdev calls pmap_mapdev_attr, and in there this evaluates to true:
/*
* If the specified range of physical addresses fits within the direct
* map window, use the direct map.
*/
if (pa dmaplimit pa + size dmaplimit) {
so we call pmap_change_attr which called pmap_change_attr_locked. It's
changing 0x1000 bytes starting at 0xff00e000. The very last line
before returning from pmap_change_attr_locked is:
pmap_invalidate_cache_range(base, tmpva);
And this is where the delay is. This is calling MFENCE/CLFLUSH in a loop 8
million times. We actually had a problem with CLFLUSH causing panics on these
same CPUs under Xen, which is partially why we're looking at VMware now. (see
kern/138863). I'm wondering if VMware didn't encounter the same problem and
replace CLFLUSH with a software emulated version that is far slower... based
on the speed is probably invalidating the entire cache. A quick change to
pmap_invalidate_cache_range to just clear the entire cache if the area being
cleared is over 8MB seems to have fixed it. i.e.:
else if (cpu_feature CPUID_CLFSH) {
to
else if ((cpu_feature CPUID_CLFSH) ((eva-sva) (222))) {
However, I'm a little blurry on if everything leading to this point is
correct. It's ending up with 256MB of memory for the pci area, which seems
really excessive. Is the problem just that it wants room for 256 busses,
or...? Anyone know this code path well enough to know if this is deviating
from the norm?
I think that the idea not to for CLFLUSH in the loop for large regions
is good. We do not extract the L2/L3 cache size now, I suppose that 2MB
estimation is good for most situations.
commit bbac1632d349d68b905df644656ce9a8e4aed094
Author: Konstantin Belousov kos...@pooma.home
Date: Wed Mar 10 13:07:51 2010 +0200
Fall back to wbinvd when region for CLFLUSH is = 2MB.
Submitted by: Kevin Day toa...@dragondata.com
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 07db5d1..4361be0 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -994,7 +994,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t
eva)
if (cpu_feature CPUID_SS)
; /* If Self Snoop is supported, do nothing. */
- else if (cpu_feature CPUID_CLFSH) {
+ else if ((cpu_feature CPUID_CLFSH) != 0
+eva - sva 2 * 1024 * 1024) {
/*
* Otherwise, do per-cache line flush. Use the mfence
@@ -1011,7 +1012,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t
eva)
/*
* No targeted cache flush methods are supported by CPU,
-* globally invalidate cache as a last resort.
+* or the supplied range is bigger then 2MB.
+* Globally invalidate cache.
*/
pmap_invalidate_cache();
}
diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c
index 4b2e34f..f448071 100644
--- a/sys/i386/i386/pmap.c
+++ b/sys/i386/i386/pmap.c
@@ -996,7 +996,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t
eva)
if (cpu_feature CPUID_SS)
; /* If Self Snoop is supported, do nothing. */
- else if (cpu_feature CPUID_CLFSH) {
+ else if ((cpu_feature CPUID_CLFSH) != 0
+eva - sva 2 * 1024 * 1024) {
/*
* Otherwise, do per-cache line flush. Use the mfence
@@ -1013,7 +1014,8 @@ pmap_invalidate_cache_range(vm_offset_t sva, vm_offset_t
eva)
/*
* No targeted cache flush methods are supported by CPU,
-* globally invalidate cache as a last resort.
+* or the supplied range is bigger then 2MB.
+* Globally invalidate
physio and vmapbuf
Hi hackers, I have some experience with other UNIX kernels but none with FreeBSD. FreeBSD interests me for a potential project I might be involved in , and therefore I started researching it. Browsing through the I/O layer code, I stumbled upon something that looked strange, and perhaps you guys can help me with it. Mainly, when reading the physio path, when the I/O buffer is from user-mode, physio calls vmapbuf. The comments says that vmapbuf actually maps the user-buffer into kernel address space. From my experience, such mapping is needed only for very old devices that use PIO. Newer device just use DMA for data copy, and therefore don't need the mapping, instead they just need to pin the memory. Checking out vmapbuf only confused me further, I couldn't find where such kernel mapping was taken place, nevertheless I did saw that the buf-b_data was updated according to buf-b_saveaddr in some weird offset calculation. Adding to this confusion, there is a buf field called b_kvabase which supposedly stores the kernel virtual address which wasn't touched at all!! Any help with understanding the flow and the usage of those fields/variables will be greatly appreciated!! ___ 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: southbridge recognition
on 10/03/2010 00:02 Ryan Stone said the following: Can you look at the device/vendor IDs of pci device 0:31:0? That's always worked for me, but I've only ever done it on Intel platforms so I'm not sure if it works on AMD chipsets. I think that better yet is to examine vendor of device 0:0:0. Something like: dev = pci_find_bsf(0, 0, 0); pci_get_vendorid(dev); With all the checks and stuff. Please keep in mind that there could be other vendors too (e.g. nvidia). Also, access to the upper RTC NVRAM bank may be disabled in chipset configuration. -- 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: southbridge recognition
on 09/03/2010 23:20 vol...@vwsoft.com said the following:
Hi!
For some driver enhancements, I need to decide (by code) which
southbridge (Intel, AMD is all that matters) the driver is facing.
What's the best (portable wise) way to distinguish the chipset?
Intel supports two pages of 128 byte CMOS RAM, AMD supports 1 page of
256 byte (addressing is different).
Is there any way to query the CMOS RAM size? I failed to find a way
while reading Intel AMD chipset documentation. Older chipsets
supported only 64 (very old) or 128 byte. Recent (as of for the last 15
years or so) chipsets supports more.
As our current nvram(4) driver only works with 128 byte RAM size, is
anybody interested in seeing the nvram(4) driver enhanced for extended
memory areas? I do have working code but that assumes an Intel ICH or
440LX chipset (fails for SB{67]xx for some reason :).
Thank you for any pointers!
Volker,
BTW, I have a couple of local patches/hacks for this myself.
But without any auto detection.
Maybe you could find some bits of them useful.
piix4-rtc-nvram-quirk.diff - enables access to upper 128 bytes on PIIX4 (440BX)
systems in chipset configuration
intel-rtc-nvram.diff - enables access to upper 128 bytes, Intel way
dev-nvram.diff - changes behavior of /dev/nvram to what is more convenient for
me,
breaks compatibility with existing apps using it (if any by now):
1) bytes are counted from offset zero, not 14, but the first 14 bytes (RTC
status
and control) are always 0xff
2) checksum is not recalculated, it's left for userland to do (not all systems
might want to do that in old BIOS way)
amd-cmos-nvram.diff - enables access to upper 128 bytes, AMD way
Two last patches are on top of the intel-rtc-nvram.diff patch, not against the
clean tree.
--
Andriy Gapon
diff --git a/sys/dev/pci/fixup_pci.c b/sys/dev/pci/fixup_pci.c
index 13fc4b1..566e503 100644
--- a/sys/dev/pci/fixup_pci.c
+++ b/sys/dev/pci/fixup_pci.c
@@ -52,6 +52,7 @@ __FBSDID($FreeBSD$);
static int fixup_pci_probe(device_t dev);
static voidfixwsc_natoma(device_t dev);
static voidfixc1_nforce2(device_t dev);
+static voidfixrtc_piix4(device_t dev);
static device_method_t fixup_pci_methods[] = {
/* Device interface */
@@ -77,6 +78,9 @@ fixup_pci_probe(device_t dev)
case 0x12378086: /* Intel 82440FX (Natoma) */
fixwsc_natoma(dev);
break;
+case 0x71108086: /* Intel PIIX4 */
+ fixrtc_piix4(dev);
+ break;
case 0x01e010de: /* nVidia nForce2 */
fixc1_nforce2(dev);
break;
@@ -105,6 +109,21 @@ fixwsc_natoma(device_t dev)
#endif
}
+/* Enable access to upper 128-byte bank of RTC NVRAM */
+static void
+fixrtc_piix4(device_t dev)
+{
+uint8_trtccfg;
+
+rtccfg = pci_read_config(dev, 0xcb, 1);
+if (!(rtccfg 0x04)) {
+ printf(Enabling access to RTC NVRAM upper 128-byte extended bank\n);
+ rtccfg |= 0x04;
+ pci_write_config(dev, 0xcb, rtccfg, 1);
+}
+}
+
+
/*
* Set the SYSTEM_IDLE_TIMEOUT to 80 ns on nForce2 systems to work
* around a hang that is triggered when the CPU generates a very fast
diff --git a/sys/dev/nvram/nvram.c b/sys/dev/nvram/nvram.c
index 164287e..7c323f7 100644
--- a/sys/dev/nvram/nvram.c
+++ b/sys/dev/nvram/nvram.c
@@ -53,7 +53,7 @@
*/
#define NVRAM_FIRSTRTC_DIAG/* 14 */
-#define NVRAM_LAST 128
+#define NVRAM_LAST 256
#define CKSUM_FIRST2
#define CKSUM_LAST 31
@@ -113,6 +113,7 @@ nvram_write(struct cdev *dev, struct uio *uio, int flags)
u_char v;
int error = 0;
int i;
+ int recalc = 0;
uint16_t sum;
sx_xlock(nvram_lock);
@@ -129,20 +130,24 @@ nvram_write(struct cdev *dev, struct uio *uio, int flags)
/* Bring in user data and write */
while (uio-uio_resid 0 error == 0) {
nv_off = uio-uio_offset + NVRAM_FIRST;
- if (nv_off NVRAM_FIRST || nv_off = NVRAM_LAST) {
- sx_xunlock(nvram_lock);
- return (0); /* Signal EOF */
- }
+ if (nv_off NVRAM_FIRST || nv_off = NVRAM_LAST)
+ break;
+ if (nv_off = (NVRAM_FIRST + CKSUM_FIRST)
+nv_off = (NVRAM_FIRST + CKSUM_LAST))
+ recalc = 1;
+
/* Single byte at a time */
error = uiomove(v, 1, uio);
writertc(nv_off, v);
}
/* Recalculate checksum afterwards */
- sum = 0;
- for (i = CKSUM_FIRST; i = CKSUM_LAST; i++)
- sum += rtcin(NVRAM_FIRST + i);
- writertc(NVRAM_FIRST + CKSUM_MSB, sum 8);
- writertc(NVRAM_FIRST + CKSUM_LSB, sum);
+ if (recalc) {
+ sum = 0;
+ for (i = CKSUM_FIRST; i = CKSUM_LAST; i++)
+ sum += rtcin(NVRAM_FIRST + i);
+ writertc(NVRAM_FIRST + CKSUM_MSB, sum 8);
+
Re: physio and vmapbuf
On Wed, Mar 10, 2010 at 01:40:18PM +0200, son goku wrote: Hi hackers, I have some experience with other UNIX kernels but none with FreeBSD. FreeBSD interests me for a potential project I might be involved in , and therefore I started researching it. Browsing through the I/O layer code, I stumbled upon something that looked strange, and perhaps you guys can help me with it. Mainly, when reading the physio path, when the I/O buffer is from user-mode, physio calls vmapbuf. The comments says that vmapbuf actually maps the user-buffer into kernel address space. From my experience, such mapping is needed only for very old devices that use PIO. Newer device just use DMA for data copy, and therefore don't need the mapping, instead they just need to pin the memory. Checking out vmapbuf only confused me further, I couldn't find where such kernel mapping was taken place, nevertheless I did saw that the buf-b_data was updated according to buf-b_saveaddr in some weird offset calculation. Adding to this confusion, there is a buf field called b_kvabase which supposedly stores the kernel virtual address which wasn't touched at all!! Any help with understanding the flow and the usage of those fields/variables will be greatly appreciated!! For normal VMIO buffers, b_kvabase is provided on the buffer initialization, see getnewbuf() and allocbuf(). b_saveaddr is initialized equial to b_kvabase. But note that physio uses pbufs, that are essentially buffer header and some reserved kva space. Note the bp = getpbuf(NULL); sa = bp-b_data; at the start of physio(), and then bp-b_saveaddr = sa; later at the buffer set up. vmapbuf() looks up the pages using vm_fault_quick()/pmap_extract_and_hold() loop, and then maps the pages into pbuf kva by pmap_qenter(). pgpn9N6oLhz8J.pgp Description: PGP signature
Re: physio and vmapbuf
On Wednesday 10 March 2010 6:40:18 am son goku wrote: Hi hackers, I have some experience with other UNIX kernels but none with FreeBSD. FreeBSD interests me for a potential project I might be involved in , and therefore I started researching it. Browsing through the I/O layer code, I stumbled upon something that looked strange, and perhaps you guys can help me with it. Mainly, when reading the physio path, when the I/O buffer is from user-mode, physio calls vmapbuf. The comments says that vmapbuf actually maps the user-buffer into kernel address space. From my experience, such mapping is needed only for very old devices that use PIO. Newer device just use DMA for data copy, and therefore don't need the mapping, instead they just need to pin the memory. Checking out vmapbuf only confused me further, I couldn't find where such kernel mapping was taken place, nevertheless I did saw that the buf-b_data was updated according to buf-b_saveaddr in some weird offset calculation. Adding to this confusion, there is a buf field called b_kvabase which supposedly stores the kernel virtual address which wasn't touched at all!! Any help with understanding the flow and the usage of those fields/variables will be greatly appreciated!! bus_dma (which drivers use to manage DMA), still uses virtual addressed buffers to build scatter/gather lists of physical addresses for DMA transfers. There has been much discussion and some prototype work to change this, but it's not a trivial project. (I have converted physio to using bio's backed by sglist's with no kernel addresses in a prototype branch in p4 for example.) -- 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
Re: Extremely slow boot on VMWare with Opteron 2352 (acpi?)
On Wednesday 10 March 2010 6:27:53 am Kostik Belousov wrote:
On Tue, Mar 09, 2010 at 06:42:02PM -0600, Kevin Day wrote:
On Mar 9, 2010, at 4:27 PM, John Baldwin wrote:
On Tuesday 09 March 2010 3:40:26 pm Kevin Day wrote:
If I boot up on an Opteron 2218 system, it boots normally. If I boot the
exact same VM moved to a 2352, I get:
acpi0: INTEL 440BX on motherboard
PCIe: Memory Mapped configuration base @ 0xe000
(very long pause)
ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48
acpi0: [MPSAFE]
acpi0: [ITHREAD]
then booting normally.
It's probably worth adding some printfs to narrow down where the pause is
happening. This looks to be all during the acpi_attach() routine, so
maybe
you can start there.
Okay, good pointer. This is what I've narrowed down:
acpi_enable_pcie() calls pcie_cfgregopen(). It's called here with
pcie_cfgregopen(0xe000, 0, 255). inside pcie_cfgregopen, the pause
starts
here:
/* XXX: We should make sure this really fits into the direct map. */
pcie_base = (vm_offset_t)pmap_mapdev(base, (maxbus + 1) 20);
pmap_mapdev calls pmap_mapdev_attr, and in there this evaluates to true:
/*
* If the specified range of physical addresses fits within the
direct
* map window, use the direct map.
*/
if (pa dmaplimit pa + size dmaplimit) {
so we call pmap_change_attr which called pmap_change_attr_locked. It's
changing 0x1000 bytes starting at 0xff00e000. The very last
line before returning from pmap_change_attr_locked is:
pmap_invalidate_cache_range(base, tmpva);
And this is where the delay is. This is calling MFENCE/CLFLUSH in a loop 8
million times. We actually had a problem with CLFLUSH causing panics on
these same CPUs under Xen, which is partially why we're looking at VMware now.
(see kern/138863). I'm wondering if VMware didn't encounter the same
problem and replace CLFLUSH with a software emulated version that is far
slower... based on the speed is probably invalidating the entire cache. A
quick change to pmap_invalidate_cache_range to just clear the entire cache if
the area being cleared is over 8MB seems to have fixed it. i.e.:
else if (cpu_feature CPUID_CLFSH) {
to
else if ((cpu_feature CPUID_CLFSH) ((eva-sva) (222))) {
However, I'm a little blurry on if everything leading to this point is
correct. It's ending up with 256MB of memory for the pci area, which seems
really excessive. Is the problem just that it wants room for 256 busses, or...?
Anyone know this code path well enough to know if this is deviating
from the norm?
I think that the idea not to for CLFLUSH in the loop for large regions
is good. We do not extract the L2/L3 cache size now, I suppose that 2MB
estimation is good for most situations.
commit bbac1632d349d68b905df644656ce9a8e4aed094
Author: Konstantin Belousov kos...@pooma.home
Date: Wed Mar 10 13:07:51 2010 +0200
Fall back to wbinvd when region for CLFLUSH is = 2MB.
Submitted by: Kevin Day toa...@dragondata.com
This looks good to me.
--
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
Re: physio and vmapbuf
Thx John for the information. Seems weird to me that FreeBSD still requires kernel mapping. There must be some performance hit due to the additional mapping which are not really needed (devices after all mostly deal with bus relative address space which is usually plain physical addresses unless there is some IOMMU). I know for sure that most modern UNIX OS, and even Windows don't generate those mapping unless the driver asked for it explicitly. I guess this is noticeable only for raw I/O from user-mode, all other IO clients (such as file-system) are kernel based so this shouldn't be an issue. I now wonder whether FreeBSD is often used for running high-performance database which use user-mode raw I/O... Many thanks, Goku. On Wed, Mar 10, 2010 at 2:53 PM, John Baldwin j...@freebsd.org wrote: On Wednesday 10 March 2010 6:40:18 am son goku wrote: Hi hackers, I have some experience with other UNIX kernels but none with FreeBSD. FreeBSD interests me for a potential project I might be involved in , and therefore I started researching it. Browsing through the I/O layer code, I stumbled upon something that looked strange, and perhaps you guys can help me with it. Mainly, when reading the physio path, when the I/O buffer is from user-mode, physio calls vmapbuf. The comments says that vmapbuf actually maps the user-buffer into kernel address space. From my experience, such mapping is needed only for very old devices that use PIO. Newer device just use DMA for data copy, and therefore don't need the mapping, instead they just need to pin the memory. Checking out vmapbuf only confused me further, I couldn't find where such kernel mapping was taken place, nevertheless I did saw that the buf-b_data was updated according to buf-b_saveaddr in some weird offset calculation. Adding to this confusion, there is a buf field called b_kvabase which supposedly stores the kernel virtual address which wasn't touched at all!! Any help with understanding the flow and the usage of those fields/variables will be greatly appreciated!! bus_dma (which drivers use to manage DMA), still uses virtual addressed buffers to build scatter/gather lists of physical addresses for DMA transfers. There has been much discussion and some prototype work to change this, but it's not a trivial project. (I have converted physio to using bio's backed by sglist's with no kernel addresses in a prototype branch in p4 for example.) -- 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
To sendmail or to postfix that is the question?
Ok so I'm looking to replace our current windows mail server using mdaemon with a FreeBSD solution, having looked around there seems to be differing opinions of which is the best option to go with between sendmail and postfix. The problem with looking for info on this is that a lot of the high listed articles in Google etc are from way back when, 2000 - 2007 during which time quite a bit can change. So what are peoples current day experience with the two options? A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? 2. Is postfix that much easier? 3. What would people use for: 3.1. POP / IMAP support? 3.2. Web Mail? 3.2. AV / Spam filtering? Any advice, opinions on a full mail solution on FreeBSD would be appreciated. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: To sendmail or to postfix that is the question?
Steven Hartland wrote: Ok so I'm looking to replace our current windows mail server using mdaemon with a FreeBSD solution, having looked around there seems to be differing opinions of which is the best option to go with between sendmail and postfix. The problem with looking for info on this is that a lot of the high listed articles in Google etc are from way back when, 2000 - 2007 during which time quite a bit can change. So what are peoples current day experience with the two options? A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? 2. Is postfix that much easier? 3. What would people use for: 3.1. POP / IMAP support? 3.2. Web Mail? 3.2. AV / Spam filtering? Any advice, opinions on a full mail solution on FreeBSD would be appreciated. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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 I'm happily using qmail for several years (but that's not what you asked about), Dovecot for POP3 and IMAP, and Roundcube for webmail. -Boris ___ 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
ctfconvert dependency...
Just trying to understand the build dependency for ctfconvert...
I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a
(cddl/lib/libctf/)
Now the snippet in bsd.lib.mk has this check for various target suffixes,
.c.So:
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
and sys.mk
.c
.if defined(CTFCONVERT)
${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.endif
My query, libctf includes bsd.lib.mk in it's Makefile, so will the above
not try to
run 'ctfconvert' on libctf itself?
___
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: physio and vmapbuf
son goku wrote: Hi hackers, I have some experience with other UNIX kernels but none with FreeBSD. FreeBSD interests me for a potential project I might be involved in , and therefore I started researching it. Browsing through the I/O layer code, I stumbled upon something that looked strange, and perhaps you guys can help me with it. Mainly, when reading the physio path, when the I/O buffer is from user-mode, physio calls vmapbuf. The comments says that vmapbuf actually maps the user-buffer into kernel address space. From my experience, such mapping is needed only for very old devices that use PIO. yes, though to some of us that is relatively recent, and in fact we still need PIO mode for quite a few devices in the embedded space. (I have a soekris machine with a flash card that I need to use PIO mode to reach). We have been saying for some time (me personally for about 18 years) that we need to handle unmapped IO better. I don't believe that it has been done yet (*), but you certainly sound like the right person to take on that project :-) (*) I last looked at physio a few years ago so if someone snuck in unmapped IO in the mean-while, please excuse me. Newer device just use DMA for data copy, and therefore don't need the mapping, instead they just need to pin the memory. Checking out vmapbuf only confused me further, I couldn't find where such kernel mapping was taken place, nevertheless I did saw that the buf-b_data was updated according to buf-b_saveaddr in some weird offset calculation. Adding to this confusion, there is a buf field called b_kvabase which supposedly stores the kernel virtual address which wasn't touched at all!! Any help with understanding the flow and the usage of those fields/variables will be greatly appreciated!! ___ 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: To sendmail or to postfix that is the question?
3.1. POP / IMAP support? about), Dovecot for POP3 and IMAP, and Roundcube for webmail. My servers use: - sendmail, I've not tried things such as qmail. One doesnt generally have to futz much with .cf files, (but its useful to look at tweak the easy bits, even if some of the lower rules are magic not for mortals ;-) Sendmail uses .mc via m4 (I keep all my .mc in a single .cpp) http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/etc/sendmail/common.cpp - /usr/ports/mail/openwebmail for webmail I'm happy with it, but I've not tried others. - /usr/ports/mail/popd /usr/local/libexec/popd (Installed but not tried popt-1.7_1 qpopper-2.53_5) With /usr/ports/mail/popd on 3 servers 1 x FreeBSD-6.3 popd-2.2.2a_4 2 x FreeBSD-7.2 popd-2.2.2a_4 I have definately received periodic data corruption, but never tracked it down to report it, I first noticed on multi meg gpg bins that wouldnt decrypt (prob one doesnt notice when people send eg pictures or .pdf or .wmv ) PS 1 I have notes on SASL with URLs to other pages. http://www.berklix.com/~jhs/txt/sasl.lmth I run majordomo, 'cos long ago I got bitten by reported a bug in mailman that would lock up a slowish server. http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/ports/gen/mail/mailman/files/ PPS I guess maybe this thread might have better started on i...@freebsd.org, but too late to move there now I suppose. You've raised interesting questions, I look forward to reading what others use. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://www.asciiribbon.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: tty or script(1) weirdness?
Hi Alfred,
* Alfred Perlstein alf...@freebsd.org wrote:
1) download the suite.
2) run sh test.sh to see the bug
3) run sh test.sh yes to not see the bug (sleep called)
Hmmm... It seems this is a TTY bug. When you close a TTY, the final
close() call should get stuck until all data is actually drained. This
doesn't seem to happen properly.
You can easily test this by performing a tcdrain() right after running
your perl script:
#include termios.h
| int
| main(int argc, char *argv[])
| {
|
| tcdrain(0);
| }
I'll see what I can do.
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgpDNzomltaDM.pgp
Description: PGP signature
Re: To sendmail or to postfix that is the question?
Steven Hartland wrote: A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? No. 2. Is postfix that much easier? Yes. 3. What would people use for: 3.1. POP / IMAP support? Dovecot. As a bonus, Postfix can use Dovecot's SASL for authentication. 3.2. Web Mail? Don't use it, sorry. 3.2. AV / Spam filtering? I can't recommend a spam filter, but greytrapping via mail/spamd is a blessing: it catches 100% of spam on my (low-volume) mail server. ___ 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: To sendmail or to postfix that is the question?
In response to Vitaly Magerya vmage...@gmail.com: 3.2. Web Mail? Don't use it, sorry. I recommend squirrelmail. Unless you require some obscene feature-rich craziness (in that case, have fun installing IMP). I've used it with Postfix/Dovecot for a few years now with no trouble. Why is this discussion on hack...@? -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ ___ 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: Extremely slow boot on VMWare with Opteron 2352 (acpi?)
On Mar 10, 2010, at 5:27 AM, Kostik Belousov wrote: I think that the idea not to for CLFLUSH in the loop for large regions is good. We do not extract the L2/L3 cache size now, I suppose that 2MB estimation is good for most situations. commit bbac1632d349d68b905df644656ce9a8e4aed094 Thanks for everyone's help. This has actually increased the boot up speed of all of our Opteron based boxes through VMware ESX. I'll report the problem to VMware, but I'm betting this is a side effect of the CLFLUSH problems in virtualized Opteron machines that they worked around with a much slower function. -- Kevin ___ 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: To sendmail or to postfix that is the question?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/10 08:47, Steven Hartland wrote: A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? No, but the m4 based configuration would make your life easier. 2. Is postfix that much easier? Yes, I would highly recommend using postfix if you don't want to spend a lot of time on mail server. As a bonus postfix have better track record in terms of security. 3. What would people use for: 3.1. POP / IMAP support? Dovecot or cyrus-imapd. I'd personally recommend dovecot for new deployments, since it supports features like using different storage for different subfolders (i.e. use Mailbox for archive, etc). 3.2. Web Mail? Connecting from IMAP: squirrelmail, roundcube, etc., I'm not a big fan of web mail though. 3.2. AV / Spam filtering? amavisd-new + clamav. Note that clamav is somewhat CPU hungry if you have high e-mail volume, consider deploying multiple layer of delivery system (multiple MX serving anti-spam purpose, and deliver to a group of backend system; this could be an overkill for small to medium sized companies, though). Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLl+8CAAoJEATO+BI/yjfBX1wIAJgT8QPLi7H2iS2RBJ8J2JDr 62ngaY0q099b8ajCgiIPWm7IMyvlEyIf3FVde9tbQls2UiojDkJR8Frd/rNGBfja mF/6tMSs77skN3vyoZzX1hj98rMbLx7ccPUwzZTFxgOsoRXpFKu+V+t9TDfqiRh5 3gSBlyinqTuoQzpO9PPjRACzY0sZLtTsyy2GoX52HeSjKn4kh2SogTcf1I9Y/+cq Eap91F4J8vKmqHh4Eqm5qAJ+WT2JwkwQpnHAjG6bej4x05kmNE6OLT7O83dip1Ga RzafJRgCPIgkSeh7f/v+rCv653jxSNswo1kJ+6HfDKkUc4l+naoP+ZKL1bo2RKo= =G5Ri -END PGP SIGNATURE- ___ 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: To sendmail or to postfix that is the question?
Steven Hartland kill...@multiplay.co.uk writes: A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? Somewhat. The configurations are done with m4 these days, but there's a lot of black magic possible with the many potential combinations of features and options. 2. Is postfix that much easier? Yes. However, the black magic in sendmail is very powerful. 3. What would people use for: 3.1. POP / IMAP support? Separate problem. I use dovecot and I like it, but it's just a household server. 3.2. Web Mail? I don't do that, because I don't want to go to the effort of making sure it is and stays secure, but from what I hear I'd probably try squirrelmail first if I were doing it. 3.2. AV / Spam filtering? I use spamassassin. You can plug most other analyzers into it. ___ 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: tty or script(1) weirdness?
* Ed Schouten e...@80386.nl wrote: Hmmm... It seems this is a TTY bug. When you close a TTY, the final close() call should get stuck until all data is actually drained. This doesn't seem to happen properly. Some further research: it's not a TTY bug, but a bug in script(1). The script parent process leaves a file descriptor open, which means output is never properly drained. I can't reproduce this issue after applying this patch: %%% Index: script.c === --- script.c(revision 204965) +++ script.c(working copy) @@ -158,6 +158,8 @@ } if (child == 0) doshell(argv); + else + close(slave); if (flushtime 0) tvp = tv; %%% -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpo052DoqSPZ.pgp Description: PGP signature
Re: namei() returns EISDIR for / (Re: svn commit: r203990 - head/lib/libc/sys)
Jaakko Heinonen schrieb am 2010-03-05: On 2010-02-28, Jaakko Heinonen wrote: http://people.freebsd.org/~jh/patches/lookup-root.diff I have updated the patch taking some of bde's comments into account. The new version also includes updates for namei(9) manual page. could this panic have been triggered by the patch? Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x12 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8048af0f stack pointer = 0x28:0xff8040495000 frame pointer = 0x28:0xff8040495020 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1402 (sh) Tracing pid 1402 tid 100092 td 0xff000729d000 strlen() at strlen+0x1f kvprintf() at kvprintf+0x1027 vsnprintf() at vsnprintf+0x48 panic() at panic+0x15f _mtx_lock_flags() at _mtx_lock_flags+0xc5 fdesc_allocvp() at fdesc_allocvp+0xbf fdesc_lookup() at fdesc_lookup+0x15c VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x11c VOP_LOOKUP() at VOP_LOOKUP+0x45 lookup() at lookup+0x8cf namei() at namei+0x730 vn_open_cred() at vn_open_cred+0x114 vn_open() at vn_open+0x55 kern_openat() at kern_openat+0x178 kern_open() at kern_open+0x3e open() at open+0x26 syscall() at syscall+0x2a7 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (5, FreeBSD ELF64, open), rip = 0x8009a3bec, rsp = 0x7fffd3c8, rbp = 0x800e143b0 --- this was 100% reducible when doing `portsnap fetch` though i changed a lot of stuff in my kernel config and reverted a lot of src patches to resolve the issue so i'm not sure what exactly was causing it. cheers. alex The patch is attached to this mail and also found at: http://people.freebsd.org/~jh/patches/lookup-root.2.diff ___ 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: To sendmail or to postfix that is the question?
Am 10.03.2010 17:47, schrieb Steven Hartland: Ok so I'm looking to replace our current windows mail server using mdaemon with a FreeBSD solution, having looked around there seems to be differing opinions of which is the best option to go with between sendmail and postfix. The best -- well, you'll know that with hindsight if you've tried both. The problem with looking for info on this is that a lot of the high listed articles in Google etc are from way back when, 2000 - 2007 during which time quite a bit can change. So what are peoples current day experience with the two options? A few key question come to mind:- 1. Has sendmail's config moved away from the black art it once was? 2. Is postfix that much easier? 3. What would people use for: 3.1. POP / IMAP support? 3.2. Web Mail? 3.2. AV / Spam filtering? sendmail's configuration was never a black art unless you needed features beyond what the m4 macro set supported. Instead, it was a matter of reading the README file and the op.* manual, writing/adjusting the .mc files, and grinding the .mc file through m4 to process it into the .cf files. Postfix can be easier to configure, and I personally prefer it over sendmail -- and it appears to have had fewer and milder security issues and a more security-aware design - and it's been faster in my setups. Still you need to understand what you're doing, and Postfix has evolved into a feature-rich MTA, so you don't get to know it in an hour of reading. I've deployed a few postfix + Dovecot + amavisd-new setups; these systems don't need webmail. I used to use sqwebmail on a few sites. -- Matthias Andree ___ 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: To sendmail or to postfix that is the question?
- Original Message - From: Bill Moran wmo...@collaborativefusion.com I recommend squirrelmail. Unless you require some obscene feature-rich craziness (in that case, have fun installing IMP). I've used it with Postfix/Dovecot for a few years now with no trouble. Why is this discussion on hack...@? Couldn't see a really appropriate list tbh, as pointed out though perhaps isp@ would have been better. Thanks for all the feedback and ideas so far :) Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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
