Picon

[PATCH] RFC: Changes to tcpbench.

Hi there,

Here is a much better diff proposal than my previous one.

- Don't fork use poll instead.

- Collect usefull overall statistics, as % bandwith being used by each
connection, total and average rate since last calculation,and peak
transfer rate.

- There is still a lot of work to be done, as the calculation time overhead
for a lot of fds is a factor.

- I've added an option (-m) which sets how many displays are done for each
individual connection prior to displaying overall stats.

I don't know if the following is acceptable:
- If we've reached the maximum number of fds, we stop polling the
listening sockets until one fd is free.
- I'm testing RLIMIT_NOFILE, and if it's lower than 1024, I'm setting it
to 1024.

My thanks to Damien Miller who helped me understanding kvm.

What do you guys think ? I'm open to any changes that might be
necessary.

What follows is an output example for 10 connections, as you can see
the calculation overhead gets higher as the fd increases. So still a
lot of work to be done.
(Continue reading)

Brad | 3 Aug 2009 06:47

Re: gem(4) flow control support

On Monday 27 July 2009 13:07:12 Brad wrote:
> On Saturday 25 July 2009 07:14:42 Brad wrote:
> > Please test the following diff which adds flow control support
> > with any gem(4) adapter.
> >
> > Please provide a dmesg and "ifconfig gemX" output.
>
> This should work with gem(4) using PHY such as brgphy(4), eephy(4),
> luphy(4), and possibly bmtphy(4) or fibre adapters with gentbi(4).
> lxtphy(4) PHY and ukphy(4) with an OUI of 0010dd model 2 (Enable
> Semiconductor PHY) will not.

I'm still looking for someone to test this with gem + brgphy or gem + eephy.
Both of these appear on models of macppc systems.

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bret S. Lambert | 3 Aug 2009 09:03
Picon
Favicon

Dynamic SysV Message Queue Implementation

The following diff makes SysV message queues and changes them from
static, boot-time to dynamic, run-time memory allocation. This makes
writing sysctls which modify the limits trivial, no longer requiring
you to recompile your kernel to do so. Also makes the code completely
machine-independent, instead of allocating the memory before the vm
system is up.

The only thing that I'm aware of that uses this (thanks to todd <at> ) is
squid with diskd. If you have that setup, please give this a test
to make sure no edge cases have crept in.

- Bert

Index: kern/sysv_msg.c
===================================================================
RCS file: /cvs/src/sys/kern/sysv_msg.c,v
retrieving revision 1.21
diff -u -p -r1.21 sysv_msg.c
--- kern/sysv_msg.c	2 Jun 2009 12:11:16 -0000	1.21
+++ kern/sysv_msg.c	3 Aug 2009 06:54:28 -0000
 <at>  <at>  -1,6 +1,20  <at>  <at> 
 /*	$OpenBSD: sysv_msg.c,v 1.21 2009/06/02 12:11:16 guenther Exp $	*/
 /*	$NetBSD: sysv_msg.c,v 1.19 1996/02/09 19:00:18 christos Exp $	*/
-
+/*
+ * Copyright (c) 2009 Bret S. Lambert <blambert <at> openbsd.org>
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
(Continue reading)

Kevin Lo | 3 Aug 2009 12:10
Picon
Favicon

alc(4) diff that needs testing

Hi,

The diff http://www.kevlo.org/alc.diff adds support for the
Atheros AR8131/AR8132 NIC(also known as Attansic L1C/L2C).

Tested on the ASUS Eee PC 1008HA:

$ dmesg | grep alc
alc0 at pci2 dev 0 function 0 "Attansic Technology L2C" rev 0xc0: apic 2
int 17 (irq 10), address 00:26:18:04:fd:9c
atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 11

$ ifconfig alc0
alc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:26:18:04:fd:9c
        priority: 0
        groups: egress
        media: Ethernet autoselect (100baseTX
full-duplex,rxpause,txpause)
        status: active
        inet6 fe80::226:18ff:fe04:fd9c%alc0 prefixlen 64 scopeid 0x1
        inet 192.168.0.143 netmask 0xffffff00 broadcast 192.168.0.255

	Kevin

Nikolay Sturm | 3 Aug 2009 16:25
Picon

OpenBSD as guest in Linux KVM

Hi,

just for the record, in order for OpenBSD to run as a guest system in
Linux KVM (I tried with OpenBSD -current/amd64 in an Ubuntu jaunty
9.04/amd64)
- change the emulated interface to e1000, otherwise you get re(4)
  watchdog timeouts
- remove the sound device from the vm, otherwise my linux machine kind
  of freezes
- disable mpbios in OpenBSD, otherwise OpenBSD freezes after mounting
  its disks

That's it, so far it works like a charm.

Nikolay

--

-- 
"It's all part of my Can't-Do approach to life." Wally

Brad | 3 Aug 2009 16:34

Re: OpenBSD as guest in Linux KVM

On Monday 03 August 2009 10:25:44 Nikolay Sturm wrote:
> Hi,
>
> just for the record, in order for OpenBSD to run as a guest system in
> Linux KVM (I tried with OpenBSD -current/amd64 in an Ubuntu jaunty
> 9.04/amd64)
> - change the emulated interface to e1000, otherwise you get re(4)
>   watchdog timeouts
> - remove the sound device from the vm, otherwise my linux machine kind
>   of freezes
> - disable mpbios in OpenBSD, otherwise OpenBSD freezes after mounting
>   its disks
>
> That's it, so far it works like a charm.

Heh. That's a pretty broken environment provided by KVM.

Why would you be using MPBIOS? KVM (QEMU) provides ACPI.

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Stuart Henderson | 3 Aug 2009 16:51
Favicon
Gravatar

Re: OpenBSD as guest in Linux KVM

On 2009/08/03 10:34, Brad wrote:
> On Monday 03 August 2009 10:25:44 Nikolay Sturm wrote:
> > Hi,
> >
> > just for the record, in order for OpenBSD to run as a guest system in
> > Linux KVM (I tried with OpenBSD -current/amd64 in an Ubuntu jaunty
> > 9.04/amd64)
> > - change the emulated interface to e1000, otherwise you get re(4)
> >   watchdog timeouts
> > - remove the sound device from the vm, otherwise my linux machine kind
> >   of freezes
> > - disable mpbios in OpenBSD, otherwise OpenBSD freezes after mounting
> >   its disks
> >
> > That's it, so far it works like a charm.
> 
> Heh. That's a pretty broken environment provided by KVM.
> 
> Why would you be using MPBIOS? KVM (QEMU) provides ACPI.

I would take a guess that it's emulating a single CPU with SMBIOS
earlier than 2.40, in which case the heuristics in bios.c would apply.

Brad | 3 Aug 2009 16:57

Re: OpenBSD as guest in Linux KVM

On Monday 03 August 2009 10:51:26 Stuart Henderson wrote:
> On 2009/08/03 10:34, Brad wrote:
> > On Monday 03 August 2009 10:25:44 Nikolay Sturm wrote:
> > > Hi,
> > >
> > > just for the record, in order for OpenBSD to run as a guest system in
> > > Linux KVM (I tried with OpenBSD -current/amd64 in an Ubuntu jaunty
> > > 9.04/amd64)
> > > - change the emulated interface to e1000, otherwise you get re(4)
> > >   watchdog timeouts
> > > - remove the sound device from the vm, otherwise my linux machine kind
> > >   of freezes
> > > - disable mpbios in OpenBSD, otherwise OpenBSD freezes after mounting
> > >   its disks
> > >
> > > That's it, so far it works like a charm.
> >
> > Heh. That's a pretty broken environment provided by KVM.
> >
> > Why would you be using MPBIOS? KVM (QEMU) provides ACPI.
>
> I would take a guess that it's emulating a single CPU with SMBIOS
> earlier than 2.40, in which case the heuristics in bios.c would apply.

That's not a very good reason.

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
(Continue reading)

Nikolay Sturm | 3 Aug 2009 17:02
Picon

Re: OpenBSD as guest in Linux KVM

* Brad [2009-08-03]:
> Heh. That's a pretty broken environment provided by KVM.
> 
> Why would you be using MPBIOS? KVM (QEMU) provides ACPI.

Because line 211 of acpimadt.c seems to fail.

Nikolay

Otto Moerbeek | 3 Aug 2009 22:05

Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel

On Tue, Jul 28, 2009 at 03:26:08PM +1000, leon zadorin wrote:

> That's all I am saying. Feel free to ignore or make "blah blah blah" noises :-)
> 
> So now we can, perhaps, get back (if at all) to the man pages and what
> they are implying wrt original question.
> 
> Leon.

I'm just back from vacation, so I'm late to jump in. The answer krw <at> 
has given is right. We (and as a consequence the kernel) take the
liberty to change fields in disklabel, especially the entry for the
'c' partition. 

Furthermore, there are partition specific entries used by fsck_ffs to
locate the alternate superblocks. These entries are NOT maintained for
the 'c' partition. 

You might want to check the source of fsck_ffs. It contains code to 
locate alternate superblocks, and that code will not work for the 'c'
partition.

As for the slighly off-topic part of the thread: if we write a
guideline into our manual page, it has a good reason to be there.
Consider the man page to be your much needed authorative source of
information. 

	-Otto

(Continue reading)


Gmane