> Probably due to the test tool you're using. Does the tool serialize the
> UDP stream (ie: wait for a response for each packet)?
As far as I understand, not it doesn't. The tool is nepim, version 0.17.
>
> BTW, this should go on freebsd-net.
OK, next time it will.
Thanks!
--
rea
BOFH excus
Good day.
Playing with OPIE I've noticed that the /etc/opiekeys have mode 644. As I
remember there was a vulnurability related to this permissions for S/Key. But
at that times that file was named /etc/skeykeys and it was created with
permissions 600, so FreeBSD was not vulnerable to the disction
> Since an OPIE password can only be used once, any program that uses OPIE
> needs to be able to read and write /etc/opiekeys. There is no valid reason
> for a program to just want to read the file.
Good point. I've missed it. Thanks.
So, the arguments for permissions 0600 instead of 0644 are g
Good day.
I am observing very low umass performance: when I am trying to move a large
file from/to my USB 2.0 flash that is plugged into the USB 2.0 port: transfer
starts fine at 3.5 Mb/sec, but after some 20 Mbytes it hangs and the process
(dd) stay in the wdrain state. The activity LED on the
>
> What is filesystem has your USB drive?
The one I was extensively testing has FAT, but I've checked the UFS2 --
just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at all.
> FreeBSD 4.x had very low performance with FAT filesystem,
> writing process spent lots of time in the wdr
> I had exactly this problem with Kingston Data Traveler II+, and
> apparently completely solved it by adding a kludge to disallow Cache
> Syncronization. Try it yourself.
And the kludge is?
--
rea
___
freebsd-hackers@freebsd.org mailing list
ht
As Ian Dowse wrote to me at Tue, Aug 30, 2005 at 08:08:57PM +0100:
> The patch in from the email below may help with the wdrain state -
> can you see if it makes any difference?
>
No, it does not make any. Mainly because my USB 2.0 controller is NEC-based
(not VIA), so LOSTINTRBUG flag is not set.
> Actually, I just peeked inside the Linux EHCI code and it does a dummy
> read immediately after writing to the status register:
>
> /* clear (just) interrupts */
> writel (status, &ehci->regs->status);
> readl (&ehci->regs->command); /* unblock posted write */
>
> I wo
> If Scott's patch doesn't work, could you have tried to install the following
> (compiles on FreeBSD 5/6/7):
Yes, it also works and does even better work: FAT 32 and FAT 16 permormance
are just the same and there is no additional load as been with the Scott's
patch.
So I definitely would vote f
> Yes, it also works and does even better work: FAT 32 and FAT 16 permormance
> are just the same and there is no additional load as been with the Scott's
> patch.
> So I definitely would vote for this fix.
Oops, it seems that this patch also does not work as expected: after some time
of playing
> > Oops, it seems that this patch also does not work as expected: after some
> > time of playing with flash card and working with the system it started to
> > stall as unpatched system, but it freezes the system -- even IP stack was
> > frozen (I am using DEVICE_POLLING), so I were to remove the
11 matches
Mail list logo
