Re: "indefinite" wait buffer patch
On Thu, Nov 01, 2007 at 09:20:42PM +0100, Arno J. Klaassen wrote:
> Hello,
>
>
> while slowly testing releng_7, I remembered I have since about
> two years the attached diff in my releng_6 sources (patch
> recreated against releng_7 with low timeouts for debugging) :
>
> it addresses the situation when one creates a huge swap-space on
> a (relatively) slow disk-subsystem : e.g. for scientific computing
> it sometimes makes sense to have, e.g. 8G swap for 2G main memory
> if you know you're treating N less then 2G matrices and process
> is CPU-bound for quite a while for 1 matrix before switching to
> the other.
> But then, when switching from one matrix to another, dmesg gets
> flooded by :
>
> "indefinite wait buffer"
>
> messages.
>
> The attached patch shows in fact that the wait buffer is never
> "indefinite" (unless a real HW-problem probably) and linearly
> increases timeout to match with reality.
I think this is mostly good. See below.
>
> The last chunk is just to prevent for a panic at reboot when
> there is so much data swapped out that is doesn't get treated
> before 'reboot-finish-time-out'.
This chunk would cause (non-silent) data corruption. Besides reboot,
the code is used when swap is turned off on live system.
Index: sys/vm/swap_pager.c
===
RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v
retrieving revision 1.295
diff -u -r1.295 swap_pager.c
--- sys/vm/swap_pager.c 5 Aug 2007 21:04:32 - 1.295
+++ sys/vm/swap_pager.c 1 Nov 2007 18:59:18 -
@@ -941,6 +941,10 @@
...
+ static int timo_secs = TIMO_START;
...
+ if (retry*TIMO_CHUNK > timo_secs) {
+ timo_secs = retry*TIMO_CHUNK;
Imagine that two buffers got the timeout on swap-in simultaneously.
I think that, instead, making timo_secs local variable would be right.
Also, timeout reading one buffer shall not increase the timeout swapping
in another one.
pgpXgf1VapjVs.pgp
Description: PGP signature
Re: timers and semtimedop(2)
On 11/1/07, Peter Jeremy <[EMAIL PROTECTED]> wrote: > On Thu, Nov 01, 2007 at 01:41:10PM -0400, Michael B Allen wrote: > >I need semtimedop(2). I'm thinking I can just do a semop with a SIGINT maybe. > > I presume you mean SIGALRM. > > >Can someone suggest a good method for setting up a timer to deliver > >the signal? What sort of timers does FreeBSD offer? > > Assuming you aren't planning on creating a new syscall: man setitimer > There's also kqueue EVFILT_TIMER but that is probably only useful if > you are already using kqueue for other purposes. Hi Peter, On second thought I decided to use the application's existing event loop to call semop and notify the waiter. It's not a self contained solution and it won't work if the event loop itself is the waiter but it it almost always pays not to use signals if you don't absolutely have to. Thanks, Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive
On Fri, Nov 02, 2007 at 11:00:26AM +0700, binto wrote: > another question. > in my 'dmesg' i have NIC - em0 Version - 6.6.6>...is it support Tigon driver that need to set > ZERO_COPY_SOCKETS ? > em(4) supports zero copy for Tx side. zero copy for receiver side requires header splitting assistance from hardware which is not available in em(4). I guess ti(4) on Tigon II would be the only driver that supports header splitting. However it seems newer Intel NICs and Sun Cassini+ seems to have header splitting feature. Jack Vogel, maintainer of em(4), may have more information for header splitting support on em(4).(CCed) > thx > > > On Fri, Nov 02, 2007 at 09:39:19AM +0700, binto wrote: > > > I try to compile MYKERNEL to set zero_copy & tigon driver in my machine > > > with: > > > > > > device ti > > > options TI_PRIVATE_JUMBOS > > > options TI_JUMBO_HDRSPLIT > > > > > > but got: > > > #error "options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually > > > exclusive" > > > > > > what's up? > > > > > > > %vi +/TI_JUMBO_HDRSPLIT /usr/src/sys/conf/NOTES > > > > -- > > Regards, > > Pyun YongHyeon > > > > -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive
On Fri, Nov 02, 2007 at 09:39:19AM +0700, binto wrote: > I try to compile MYKERNEL to set zero_copy & tigon driver in my machine > with: > > device ti > options TI_PRIVATE_JUMBOS > options TI_JUMBO_HDRSPLIT > > but got: > #error "options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually > exclusive" > > what's up? > %vi +/TI_JUMBO_HDRSPLIT /usr/src/sys/conf/NOTES -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive
I try to compile MYKERNEL to set zero_copy & tigon driver in my machine with: device ti options TI_PRIVATE_JUMBOS options TI_JUMBO_HDRSPLIT but got: #error "options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive" what's up? thx ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory pool, rfc
On 2007-11-01 12:45, Eduardo Morras <[EMAIL PROTECTED]> wrote: > At 01:57 01/11/2007, you wrote: >> On Thu, Nov 01, 2007 at 01:05:54AM +0100, Eduardo Morras wrote: >> > Don't point me to zlib or libbzip2, they are on another league and are >> much >> > slower than my code. >> >> Have you looked at liblzo? > > Yes, i know lzo, i'm working with compression since '99. My code has > similar compression efficience but is low size block oriented and faster on > compression/decompression. > > Giorgios Keramidas suggested on freebsd-question to prepare a paper and > code about it Yep. Thank you for actually *posting* about it on -hackers. I'll be glad to see this actually hit the tree with some useful and well-implemented feature in the future :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Patch RFC: Promise SATA300 TX4 hardware bug workaround.
Hello.
I have ported the workaround for the hardware bug that causes data
corruption on Promise SATA300 TX4 cards to RELENG_7.
Bug description:
SATA300 TX4 hardware chokes if last PRD entry (in a dma transfer) is
larger than 164 bytes. This was found while analysing vendor-supplied
linux driver.
Workaround:
Split trailing PRD entry if it's larger that 164 bytes.
Two supplied patches do fix problem on my machine.
There is, however, a style problem with them. It seems like PRD entry
count is limited at 256. I have not found a good way to guarantee that
one entry is always available to do the split, thus the ugly solution of
patching ata-dma.c.
Patches, patched and original files are at http://lxnt.info/tx4/freebsd/.
--- ata-chipset.c.orig 2007-11-02 01:05:49.0 +0300
+++ ata-chipset.c 2007-11-02 01:05:49.0 +0300
@@ -142,6 +142,7 @@
static int ata_promise_mio_command(struct ata_request *request);
static void ata_promise_mio_reset(device_t dev);
static void ata_promise_mio_dmainit(device_t dev);
+static void ata_promise_mio_dmasetprd(void *xsc, bus_dma_segment_t
*segs, int nsegs, int error);
static void ata_promise_mio_setmode(device_t dev, int mode);
static void ata_promise_sx4_intr(void *data);
static int ata_promise_sx4_command(struct ata_request *request);
@@ -185,7 +186,6 @@
static int ata_check_80pin(device_t dev, int mode);
static int ata_mode2idx(int mode);
-
/*
* generic ATA support functions
*/
@@ -3759,8 +3759,44 @@
static void
ata_promise_mio_dmainit(device_t dev)
{
+struct ata_channel *ch = device_get_softc(dev);
+
/* note start and stop are not used here */
ata_dmainit(dev);
+
+if (ch->dma)
+ ch->dma->setprd = ata_promise_mio_dmasetprd;
+}
+
+static void
+ata_promise_mio_dmasetprd(void *xsc, bus_dma_segment_t *segs, int
nsegs, int error)
+{
+#define PDC_MAXLASTSGSIZE 41*4
+struct ata_dmasetprd_args *args = xsc;
+struct ata_dma_prdentry *prd = args->dmatab;
+int i;
+
+if ((args->error = error))
+ return;
+
+for (i = 0; i < nsegs; i++) {
+ prd[i].addr = htole32(segs[i].ds_addr);
+ prd[i].count = htole32(segs[i].ds_len);
+}
+
+if (segs[i - 1].ds_len > PDC_MAXLASTSGSIZE) {
+ /*
+ printf("splitting trailing PRD of %ld (limit %d)\n", segs[i -
1].ds_len, PDC_MAXLASTSGSIZE);
+ */
+ prd[i - 1].count = htole32(segs[i - 1].ds_len - PDC_MAXLASTSGSIZE);
+ prd[i].count = htole32(PDC_MAXLASTSGSIZE);
+ prd[i].addr = htole32(segs[i - 1].ds_addr + PDC_MAXLASTSGSIZE);
+ i ++;
+ nsegs ++;
+}
+
+prd[i - 1].count |= htole32(ATA_DMA_EOT);
+args->nsegs = nsegs;
}
static void
--- ata-dma.c.orig 2007-11-02 01:05:53.0 +0300
+++ ata-dma.c 2007-11-02 01:05:53.0 +0300
@@ -113,7 +113,7 @@
if
(bus_dma_tag_create(ch->dma->dmatag,ch->dma->alignment,ch->dma->boundary,
ch->dma->max_address, BUS_SPACE_MAXADDR,
NULL, NULL, ch->dma->max_iosize,
- ATA_DMA_ENTRIES, ch->dma->segsize,
+ ATA_DMA_ENTRIES - 1, ch->dma->segsize,
0, NULL, NULL, &ch->dma->data_tag))
goto error;
--
./lxnt
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
"indefinite" wait buffer patch
Hello, while slowly testing releng_7, I remembered I have since about two years the attached diff in my releng_6 sources (patch recreated against releng_7 with low timeouts for debugging) : it addresses the situation when one creates a huge swap-space on a (relatively) slow disk-subsystem : e.g. for scientific computing it sometimes makes sense to have, e.g. 8G swap for 2G main memory if you know you're treating N less then 2G matrices and process is CPU-bound for quite a while for 1 matrix before switching to the other. But then, when switching from one matrix to another, dmesg gets flooded by : "indefinite wait buffer" messages. The attached patch shows in fact that the wait buffer is never "indefinite" (unless a real HW-problem probably) and linearly increases timeout to match with reality. The last chunk is just to prevent for a panic at reboot when there is so much data swapped out that is doesn't get treated before 'reboot-finish-time-out'. With this patch, dmesg lookes like following (with low timeout values, on production systems I use TIMO_CHUNK 20 TIMO_START 1O ) : Nov 1 20:09:52 install kernel: swap_pager: wait buffer timeout 1 (1 secs): bufobj: 0, blkno: 1649, size: 28672 Nov 1 20:09:52 install kernel: swap_pager: wait buffer timeout 2 (2 secs): bufobj: 0, blkno: 1649, size: 28672 Nov 1 20:09:52 install kernel: swap_pager: wait buffer completed (2 retry): bufobj: 0, blkno: 1649, size: 28672 Nov 1 20:37:09 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 329073, size: 32768 Nov 1 20:37:10 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 329073, size: 32768 Nov 1 20:39:06 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 381137, size: 32768 Nov 1 20:39:07 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 381137, size: 32768 Nov 1 20:39:11 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 381161, size: 32768 Nov 1 20:39:14 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 381161, size: 32768 Nov 1 20:39:19 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 381209, size: 32768 Nov 1 20:39:20 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 381209, size: 32768 Nov 1 20:43:18 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 300329, size: 32768 Nov 1 20:43:18 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 300329, size: 32768 Nov 1 20:44:23 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 330617, size: 32768 Nov 1 20:44:24 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 330617, size: 32768 Nov 1 20:44:28 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 330649, size: 32768 Nov 1 20:44:28 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 330649, size: 32768 Nov 1 20:44:33 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 330665, size: 32768 Nov 1 20:44:36 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 330665, size: 32768 Nov 1 20:45:18 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 356481, size: 32768 Nov 1 20:45:18 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 356481, size: 32768 Nov 1 20:45:23 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 356521, size: 32768 Nov 1 20:45:27 install kernel: swap_pager: wait buffer timeout 2 (4 secs): bufobj: 0, blkno: 356521, size: 32768 Nov 1 20:45:31 install kernel: swap_pager: wait buffer completed (2 retry): bufobj: 0, blkno: 356521, size: 32768 Nov 1 20:46:37 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 391113, size: 32768 Nov 1 20:46:37 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 391113, size: 32768 Nov 1 20:46:42 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 391129, size: 32768 Nov 1 20:46:45 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 391129, size: 32768 Nov 1 20:48:18 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 432249, size: 32768 Nov 1 20:48:18 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 432249, size: 32768 Nov 1 20:48:25 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 432273, size: 32768 Nov 1 20:48:25 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 432273, size: 32768 (And then the timeout of 8 secs apperently is enough for this test setup). Any thoughts? Regards, Arno Index: sys/vm/swap_pager.c
Re: Attansic L1 Gigabit LAN Controller
Hi, I'm looking for a FreeBSD driver for the Attansic L1 Gigabit LAN Controller (used by ASUS and to my eternal shame I did not check the FreeBSD compatible hardware list before buying the P5L-VM 1394 motherboard .. silly really as I've been using FreeBSD as my server OS since 8-). According to the archives, Alex Lukin has been working on porting one and I'd love to get hold of the latest version and help out with development. So if Alex is around could you contact me and let me have the patch(es)? Thanks very much. Cheers, Richard ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: floating point operations
On Thu, Nov 01, 2007, Dag-Erling Smørgrav wrote: > James Healy <[EMAIL PROTECTED]> writes: > > The remaining op is not easily converted to fixed point math, and we're > > wondering what impact a single flop on the receipt of each ACK will > > have. We don't have a strong understanding of the amount of overhead > > involved in executing a flop instead of an int op on modern hardware. > > Search the archives before posting. This precise topic was discussed > here earlier this week. The earlier thread was about a special-purpose variant of FreeBSD where user applications didn't use floating point, so don't assume that just because they got it to work it's a good idea in general. Floating point is often faster if it would take a lot more work to express the equivalent computation in terms of integers. On many processors, multiplying by 0.01 is faster than dividing by 100. HOWEVER, in the kernel all of this is likely to be dwarfed by the overhead of saving and restoring the FPU state. See the earlier thread for details. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: timers and semtimedop(2)
"Michael B Allen" <[EMAIL PROTECTED]> writes: > I need semtimedop(2). I'm thinking I can just do a semop with a SIGINT > maybe. > > Can someone suggest a good method for setting up a timer to deliver > the signal? What sort of timers does FreeBSD offer? man alarm DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
timers and semtimedop(2)
Hi, I need semtimedop(2). I'm thinking I can just do a semop with a SIGINT maybe. Can someone suggest a good method for setting up a timer to deliver the signal? What sort of timers does FreeBSD offer? Thanks, Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Useful tools missing from /rescue
On Thu, Oct 18, 2007 at 02:04:21AM +0400, Yar Tikhiy wrote: > On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: > > I guess I'm not creative enough in the ways I've screwed up my systems > > and needed tools from /rescue. 8-) > > Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) I strongly feel that shouldn't be supported on a live system. So to me it shouldn't be an excuse to put a duplicated copy of /usr/[s]bin into /rescue. It is a delicate thing to get right - and there are easy ways to do it today: Boot from disc1; mount / and /usr; mv /mnt/etc /mnt/etc.hold; rm -rf the bits in bin,sbin,libexec; then run the install.sh from the disc1; mv /mnt/etc /mnt/etc.new ; mv /mnt/etc.hold /mnt/etc -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory pool, rfc
Hello; You might want to compare your code with archivers/lzo, which is meant to be faster that the other archivers but is GPLd. Just to mention .. NetBSD has a pool(9) that you might want to check out. I think it was used in the original tmpfs: http://www.freebsd.org/cgi/man.cgi?query=pool&apropos=0&sektion=0&manpath=NetBSD+3.0&format=html Also ... if you're way too enterprising you might want to look at Heidemann's Ph. D. thesis http://www.isi.edu/~johnh/PAPERS/Heidemann95a.html A compression fs layer has always been a greatly desired feature (I think). cheers, Pedro. Comparte video en la ventana de tus mensajes (y también tus fotos de Flickr). Usa el nuevo Yahoo! Messenger versión Beta. http://e1.beta.messenger.yahoo.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory pool, rfc
At 01:57 01/11/2007, you wrote: On Thu, Nov 01, 2007 at 01:05:54AM +0100, Eduardo Morras wrote: > Don't point me to zlib or libbzip2, they are on another league and are much > slower than my code. Have you looked at liblzo? Yes, i know lzo, i'm working with compression since '99. My code has similar compression efficience but is low size block oriented and faster on compression/decompression. Giorgios Keramidas suggested on freebsd-question to prepare a paper and code about it Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory pool, rfc
On Thu, Nov 01, 2007 at 01:05:54AM +0100, Eduardo Morras wrote: > Don't point me to zlib or libbzip2, they are on another league and are much > slower than my code. Have you looked at liblzo? Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: floating point operations
James Healy <[EMAIL PROTECTED]> writes: > The remaining op is not easily converted to fixed point math, and we're > wondering what impact a single flop on the receipt of each ACK will > have. We don't have a strong understanding of the amount of overhead > involved in executing a flop instead of an int op on modern hardware. Search the archives before posting. This precise topic was discussed here earlier this week. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
