mailing.openbsd.tech
  Home FAQ Contact Sign in
mailing.openbsd.tech only
 
Advanced search
March 2008
motuwethfrsasuw
     12 9
3456789 10
10111213141516 11
17181920212223 12
24252627282930 13
31       14
2008
 Jan   Feb   Mar   Apr 
 May   Jun   Jul   Aug 
 Sep   Oct   Nov   Dec 
2008 2007 2006  
total
mailing.openbsd.tech Profile…
RELATED GROUPS

POPULAR GROUPS

more...

 Up
  Re: [PATCH] optimization for sys/netinet/ip_id.c         


Author: Daniel Dickman
Date: Mar 12, 2008 21:04

>> Minor optimization from Knuth to the shuffle algorithm. Eliminates the
>> first loop and having to do the exchange in the 2nd loop.
>>
>> Patch can be found here:
>> http://www.dickman.org/openbsd/knuth_shuffle.patch
>
> Won't counting backwards produce better mixing of the lower-order members
> of the set?

Hi Damien,

If you count backwards, I think you'd need the array to be initialized
already which gets us back to the code that's in the tree right now.
So what we're doing today is first initializing an array with a
sequence of integers and then shuffling them. That's actually not
needed, we can initialize and shuffle at the same time since we don't
need to handle the general case of shuffling an *arbitrary* set of
numbers.
Show full article (1.25Kb)
no comments
  Re: [PATCH] optimization for sys/netinet/ip_id.c         


Author: Damien Miller
Date: Mar 12, 2008 18:05

On Wed, 12 Mar 2008, Daniel Dickman wrote:
> Minor optimization from Knuth to the shuffle algorithm. Eliminates the
> first loop and having to do the exchange in the 2nd loop.
>
> Patch can be found here:
> http://www.dickman.org/openbsd/knuth_shuffle.patch

Won't counting backwards produce better mixing of the lower-order members
of the set?

-d
no comments
  Re: re(4) RX FIFO threshold diff needs testing.         


Author: Ivan Solonin
Date: Mar 12, 2008 16:41

Brad comstyle.com> wrote:
> Please test the following diff which adjusts the RX FIFO threshold
handling
> for re(4) chipsets. Please provide a dmesg.
>
>
> Index: re.c
> ===================================================================

On landisk platform this patch works fine.

OpenBSD 4.3-current (PX-EH) #0: Thu Mar 13 04:05:48 YEKT 2008
root@ld2.my.domain:/usr/src/sys/arch/landisk/compile/PX-EH
I-O DATA USL-5P
real mem = 67108864 (65536K)
avail mem = 63590400 (62100K)
mainbus0...
Show full article (2.00Kb)
no comments
  [PATCH] optimization for sys/netinet/ip_id.c         


Author: Daniel Dickman
Date: Mar 12, 2008 15:53

Minor optimization from Knuth to the shuffle algorithm. Eliminates the
first loop and having to do the exchange in the 2nd loop.

Patch can be found here:
http://www.dickman.org/openbsd/knuth_shuffle.patch
no comments
  Re: re(4) RX FIFO threshold diff needs testing.         


Author: Markus Hennecke
Date: Mar 12, 2008 12:39

On Sun, 9 Mar 2008, Brad wrote:
> Please test the following diff which adjusts the RX FIFO threshold handling
> for re(4) chipsets. Please provide a dmesg.

This seems to fix the freeze issue with my re0 card and multicast
packets. dmesg is below.

Kind regards,
Markus

OpenBSD 4.3-current (GENERIC.MP) #2: Sun Mar 9 12:28:46 CET 2008
markus@teiresias.markus-hennecke.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3476586496 (3315MB)
avail mem = 3373002752...
Show full article (8.29Kb)
no comments
  [patch] opencvs:tag.c probably missed rcsnum_free() when doing tag_add()         


Author: Igor Zinovik
Date: Mar 12, 2008 07:21

Hello, tech@ readers.

When we adding tag to a file, function `tag_add' tries to check is this
file already tagged with provided symbolic tag. It obtains file
revision `trev' with `rcs_sym_getrev' function. rcs_sym_getrev()
dynamically allocates memory for RCSNUM and considers that caller will
free it with rcsnum_free() when there is no need to use RCSNUM it
returned. `trev' is only freed when it is the same as `srev', but it is
not freed when this test fails. It seems that we should free `trev'
just after rcsnum_tostr() call.

--- tag.c.orig Wed Mar 12 16:07:59 2008
+++ tag.c Wed Mar 12 16:12:49 2008
@@ -314,6 +314,7 @@ tag_add(struct cvs_file *cf)
return (-1);
}
(void)rcsnum_tostr(trev, trevbuf, sizeof(trevbuf));
+ rcsnum_free(trev);

if (!(runflags & T_FORCE_MOVE)) {
cvs_printf("W %%s : %%s ", cf->file_path, tag_name);
no comments
  Re: re(4) RX FIFO threshold diff needs testing.         


Author: nikolai
Date: Mar 12, 2008 07:08

> Please test the following diff which adjusts the RX FIFO threshold
> handling
> for re(4) chipsets. Please provide a dmesg.
>

Looks like everything is working. Thanks.
--
Nikolai

OpenBSD 4.3-current (GENERIC) #3: Wed Mar 12 09:29:16 EDT 2008
nickf@login.ipv6.fetissov.org:/hack/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(TM) CPU 1400MHz ("GenuineIntel" 686-class...
Show full article (3.64Kb)
no comments
  Re: re(4) RX FIFO threshold diff needs testing.         


Author: Alexey Suslikov
Date: Mar 12, 2008 03:43

Brad wrote:
> On Sunday 09 March 2008 01:29:03 Brad wrote:
>> Please test the following diff which adjusts the RX FIFO threshold handling
>> for re(4) chipsets. Please provide a dmesg.
>
> I could still use a few more tests for this.
>

Btw, looks like we have 5(!) tickets in the tracker about this issue:

5334, 5504, 5706 (closed due to no hardware on reporter's side),
5415 and, of course, 5759.

- Alexey.
no comments