Re: FB9-stable: bridge0 doesn't come up via rc *SOLVED*

2012-01-18 Thread Denny Schierz
hi,

for google:

Am 18.01.2012 um 08:15 schrieb Denny Schierz:

 
 Am 17.01.2012 um 14:23 schrieb Stefan Esser:
 
 You forgot that rc.conf does not contain commands, but only variable
 assignments. The latter of the last two lines overwrites the value
 set in the former.
 
 ah, ok, that wasn't clear for me. I tried several combinations, so I try it 
 again. Thanks a lot @Stefan and @Volodymyr

/etc/rc.conf
[...]
ifconfig_bridge0=addm bge0 up
ifconfig_bridge0_alias0=inet 192.168.1.1 netmask 255.255.255.0 up
ifconfig_bge0=up
defaultrouter=192.168.1.254
[...]___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Fighting with vnet / jails epair and so on

2012-01-18 Thread Denny Schierz
hi,

after most parts works with my bridge setups works, I want to get vnet for my 
jails working. In the morning I started a jail and got only the local interface 
back, but no epair0b. Now I did something so that I can see _all_ interfaces 
from outside (bridge0 / bge* / epair0* ... ) but without any IPs.
However, I'm not able to give epair0b inside the jail an ip address. I get 
permission denied.

Also  it looks a bit strange:

===
host# jexec 2 ifconfig

bge0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 
1500
options=80099RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
ether CHANGED
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
media: Ethernet autoselect (1000baseT full-duplex)
status: active
bge1: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500

options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
ether CHANGED
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
media: Ethernet autoselect (none)
status: no carrier
bge2: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500

options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
ether CHANGED
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
media: Ethernet autoselect (none)
status: no carrier
bge3: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500

options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
ether CHANGED
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
media: Ethernet autoselect (1000baseT full-duplex)
status: active
pflog0: flags=0 metric 0 mtu 33152
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
ipfw0: flags=8801UP,SIMPLEX,MULTICAST metric 0 mtu 65536
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
options=3RXCSUM,TXCSUM
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
ether CHANGED
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: epair0a flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
ifmaxaddr 0 port 12 priority 128 path cost 2000
member: bge0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
ifmaxaddr 0 port 4 priority 128 path cost 55
epair0a: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 
mtu 1500
options=8VLAN_MTU
ether CHANGED
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
media: Ethernet 10Gbase-T (10Gbase-T full-duplex)
status: active
epair0b: flags=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
options=8VLAN_MTU
ether CHANGED
ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
media: Ethernet 10Gbase-T (10Gbase-T full-duplex)
status: active
===

# host: 
jexec 2 ifconfig epair0b 192.168.1.2 netmask 255.255.255.0 up
ifconfig: up: permission denied



# sysctl:

security.jail.enforce_statfs: 2
security.jail.mount_allowed: 0
security.jail.chflags_allowed: 0
security.jail.allow_raw_sockets: 1
security.jail.sysvipc_allowed: 1
security.jail.socket_unixiproute_only: 1
security.jail.set_hostname_allowed: 1
security.jail.jail_max_af_ips: 255
security.jail.jailed: 0

/etc/rc.conf:
=
jail_enable=YES
jail_v2_enable=YES
jail_list=
jail_sysvipc_allow=YES


#JAIL template
jail_list=$jail_list template
jail_template_name=template
jail_template_hostname=template.CHANGED
jail_template_devfs_enable=YES
jail_template_rootdir=/jails/template
jail_template_mount_enable=YES
jail_template_fstab=/etc/jails/fstabs/template
jail_template_vnet_enable=YES
jail_template_devfs_ruleset=devfsrules_jail
 
#network
jail_template_exec_prestart0=ifconfig epair0 create
jail_template_exec_prestart1=ifconfig bridge0 addm epair0a
jail_template_exec_prestart2=ifconfig epair0a up
jail_template_exec_earlypoststart0=ifconfig epair0b vnet template
jail_template_exec_afterstart0=ifconfig lo0 127.0.0.1
jail_template_exec_afterstart1=ifconfig epair0b 192.168.1.2 netmask 
255.255.255.0 up
jail_template_exec_afterstart2=route add default 130.83.160.62
jail_template_exec_afterstart3=/bin/sh /etc/rc
jail_template_exec_poststop0=ifconfig bridge0 deletem epair0a
jail_template_exec_poststop1=ifconfig epair0a destroy

===

Starting jail:

#/etc/rc.d/jail onestart

Configuring jails:.
Starting jails:epair0a
ifconfig: up: permission denied
route: writing to routing socket: Operation not permitted
Setting hostname: example.mydomain.com.


Re: about thumper aka sun fire x4500

2012-01-18 Thread peter h
On Tuesday 17 January 2012 22.52, Patrick M. Hausen wrote:
 Hi, all,
 
 Am 17.01.2012 um 18:59 schrieb peter h pe...@hk.ipsec.se:
 
  I have been beating on of these a few days, i have udes freebsd 9.0 and 8.2
  Both fails when i engage  10 disks, the system craches and messages :
  Hyper transport sync flood will get into the BIOS errorlog ( but nothing 
  will
  come to syslog since reboot is immediate)
  
  Using a zfs radz of 25 disks and typing zpool scrub will bring the system 
  down in seconds.
  
  Anyone using a x4500 that can comfirm that it works ? Or is this box broken 
  ?
 
 Well, I hate to write that, but ... does it work with the vendor supported 
 [tm] OS?
 If yes, you can rule out a hardware defect. I would at least try Solaris for 
 this reason.
 If no, the HW is broken and there is no need to look for a fault on FreeBSD's 
 side.
 
 Kind regards,
 Patrick
 
today i installed nexenta ( 134) , built a simular raidz and it _seems_ to stay 
up.
I'll come back when i have made the same pressure on it.


-- 
Peter Håkanson   

There's never money to do it right, but always money to do it
again ... and again ... and again ... and again.
( Det är billigare att göra rätt. Det är dyrt att laga fel. )
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Fighting with vnet / jails epair and so on

2012-01-18 Thread Shawn Webb
I've done a bit of research about vnet jails:
http://archive.0xfeedface.org/blog/2011-11-21/lattera/freebsd-vnet-jail-admin-project

On Wed, Jan 18, 2012 at 6:59 AM, Denny Schierz linuxm...@4lin.net wrote:
 hi,

 after most parts works with my bridge setups works, I want to get vnet for my 
 jails working. In the morning I started a jail and got only the local 
 interface back, but no epair0b. Now I did something so that I can see _all_ 
 interfaces from outside (bridge0 / bge* / epair0* ... ) but without any IPs.
 However, I'm not able to give epair0b inside the jail an ip address. I get 
 permission denied.

 Also  it looks a bit strange:

 ===
 host# jexec 2 ifconfig

 bge0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 
 1500
        options=80099RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
        ether CHANGED
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
 bge1: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500
        
 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
        ether CHANGED
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
        media: Ethernet autoselect (none)
        status: no carrier
 bge2: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500
        
 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
        ether CHANGED
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
        media: Ethernet autoselect (none)
        status: no carrier
 bge3: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500
        
 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
        ether CHANGED
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
 pflog0: flags=0 metric 0 mtu 33152
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
 ipfw0: flags=8801UP,SIMPLEX,MULTICAST metric 0 mtu 65536
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
        options=3RXCSUM,TXCSUM
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
 bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
        ether CHANGED
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: epair0a flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
                ifmaxaddr 0 port 12 priority 128 path cost 2000
        member: bge0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP
                ifmaxaddr 0 port 4 priority 128 path cost 55
 epair0a: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 
 mtu 1500
        options=8VLAN_MTU
        ether CHANGED
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
        media: Ethernet 10Gbase-T (10Gbase-T full-duplex)
        status: active
 epair0b: flags=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
        options=8VLAN_MTU
        ether CHANGED
 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported
        media: Ethernet 10Gbase-T (10Gbase-T full-duplex)
        status: active
 ===

 # host:
 jexec 2 ifconfig epair0b 192.168.1.2 netmask 255.255.255.0 up
 ifconfig: up: permission denied



 # sysctl:

 security.jail.enforce_statfs: 2
 security.jail.mount_allowed: 0
 security.jail.chflags_allowed: 0
 security.jail.allow_raw_sockets: 1
 security.jail.sysvipc_allowed: 1
 security.jail.socket_unixiproute_only: 1
 security.jail.set_hostname_allowed: 1
 security.jail.jail_max_af_ips: 255
 security.jail.jailed: 0

 /etc/rc.conf:
 =
 jail_enable=YES
 jail_v2_enable=YES
 jail_list=
 jail_sysvipc_allow=YES


 #JAIL template
 jail_list=$jail_list template
 jail_template_name=template
 jail_template_hostname=template.CHANGED
 jail_template_devfs_enable=YES
 jail_template_rootdir=/jails/template
 jail_template_mount_enable=YES
 jail_template_fstab=/etc/jails/fstabs/template
 jail_template_vnet_enable=YES
 jail_template_devfs_ruleset=devfsrules_jail

 #network
 jail_template_exec_prestart0=ifconfig epair0 create
 jail_template_exec_prestart1=ifconfig bridge0 addm epair0a
 jail_template_exec_prestart2=ifconfig epair0a up
 jail_template_exec_earlypoststart0=ifconfig epair0b vnet template
 jail_template_exec_afterstart0=ifconfig lo0 127.0.0.1
 jail_template_exec_afterstart1=ifconfig epair0b 192.168.1.2 netmask 
 255.255.255.0 up
 jail_template_exec_afterstart2=route add default 130.83.160.62
 jail_template_exec_afterstart3=/bin/sh /etc/rc
 jail_template_exec_poststop0=ifconfig bridge0 deletem epair0a
 

Re: Fighting with vnet / jails epair and so on

2012-01-18 Thread Bjoern A. Zeeb

On 18. Jan 2012, at 15:13 , Shawn Webb wrote:

 I've done a bit of research about vnet jails:
 http://archive.0xfeedface.org/blog/2011-11-21/lattera/freebsd-vnet-jail-admin-project

There's a simple shell script sample on the wiki as well but it would be really 
cool if you guys could help testing and review the framework jamie has posted 
on freebsd-jails@ in the past and give him feedback to get it into the tree.

/bz

 
 On Wed, Jan 18, 2012 at 6:59 AM, Denny Schierz linuxm...@4lin.net wrote:
 hi,
 
 after most parts works with my bridge setups works, I want to get vnet for 
 my jails working. In the morning I started a jail and got only the local 
 interface back, but no epair0b. Now I did something so that I can see _all_ 
 interfaces from outside (bridge0 / bge* / epair0* ... ) but without any IPs.
 However, I'm not able to give epair0b inside the jail an ip address. I get 
 permission denied.
 
 Also  it looks a bit strange:
 
 ===
-- 
Bjoern A. Zeeb You have to have visions!
   It does not matter how good you are. It matters what good you do!

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: about thumper aka sun fire x4500

2012-01-18 Thread Adam McDougall

On 01/17/12 17:09, Jeremy Chadwick wrote:

On Tue, Jan 17, 2012 at 06:59:08PM +0100, peter h wrote:

I have been beating on of these a few days, i have udes freebsd 9.0 and 8.2
Both fails when i engage  10 disks, the system craches and messages :
Hyper transport sync flood will get into the BIOS errorlog ( but nothing will
come to syslog since reboot is immediate)

Using a zfs radz of 25 disks and typing zpool scrub will bring the system 
down in seconds.

Anyone using a x4500 that can comfirm that it works ? Or is this box broken ?




I've seen what is probably the same base issue but on multiple x4100m2 
systems running FreeBSD 7 or 8 a few years ago.  For me the instant 
reboot and HT sync flood error happened when I fetched a ~200mb file via 
HTTP using an onboard intel nic and wrote it out to a simple zfs mirror 
on 2 disks.  I may have tried the nvidia ethernet ports as an 
alternative but that driver had its own issues at the time.  This was 
never a problem with FFS instead of ZFS.  I could repeat it fairly 
easily by running fetch in a loop (can't remember if writing the output 
to disk was necessary to trigger it).  The workaround I found that 
worked for me was to buy a cheap intel PCIE nic and use that instead of 
the onboard ports.  If a zpool scrub triggers it for you, I doubt my 
workaround will help but I wanted to relate my experience.



Given this above diagram, I'm sure you can figure out how flooding
might occur.  :-)  I'm not sure what sync flood means (vs. I/O
flooding).


As I understand it, a sync flood is a purposeful reaction to an error 
condition as somewhat of a last ditch effort to regain control over the 
system (which ends up rebooting).  I'm pulling this out of my memory 
from a few years ago.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


problems with hast

2012-01-18 Thread Artem Kajalainen
Hello,

I'm trying to setup hastd on two servers and got error, which I can't
understand. Box is running as primary, then i reboot it, another box
get primary role by carp events, then 1st box at boot tries to set up
primary role on own hast instance and fails with this:
Jan 18 22:13:03 gw_chlb_2 hastd[1387]: [storage0] (primary)
G_GATE_CMD_DONE failed: No such file or directory.
Jan 18 22:13:08 gw_chlb_2 hastd[1004]: [storage0] (primary) Worker
process exited ungracefully (pid=1387, exitcode=71).

I thought that geom_gate module can be problem, so i compiled it in
kernel. As you can see - it doesn't help. Both servers are
FreeBSD9.0-stable, updated 1 week ago. Hastd use whole disk. More info
from hastd:
gw_chlb_2# hastd -dF -c /etc/hast.conf
[INFO] Started successfully, running protocol version 1.
[DEBUG][1] Listening on control address /var/run/hastctl.
[INFO] Listening on address 192.168.0.1:8457.
[INFO] [storage0] (init) Role changed to primary.
[DEBUG][1] [storage0] (primary) Obtained info about /dev/ada2.
[DEBUG][1] [storage0] (primary) Locked /dev/ada2.
[INFO] [storage0] (primary) Device hast/storage0 created.
[DEBUG][1] [storage0] (primary) Privileges successfully dropped using
jail+setgid+setuid.
[INFO] [storage0] (primary) Privileges successfully dropped.
[INFO] [storage0] (primary) Connected to tcp4://192.168.0.2.
[INFO] [storage0] (primary) Synchronization started. 6.0MB to go.
[ERROR] [storage0] (primary) G_GATE_CMD_DONE failed: No such file or directory.
[INFO] [storage0] (primary) Received cancel from the kernel, exiting.
[DEBUG][1] Unable to receive event header: Socket is not connected.
[ERROR] [storage0] (primary) Worker process exited ungracefully
(pid=1452, exitcode=71).
[INFO] [storage0] (primary) Changing resource role back to init.

Any thoughts?

---
With Best Regards / Ystävällisin terveisin
Artem Kajalainen
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Timekeeping in stable/9

2012-01-18 Thread Ian Lepore
On Tue, 2012-01-17 at 20:12 +, Joe Holden wrote:
 Hi guys,
 
 Has anyone else noticed the tendency for 9.0-R to be unable to 
 accurately keep time?  I've got a couple of machines that have been 
 upgraded from 8.2 that are struggling, in particular a Virtual box guest 
 that was fine on 8.2, but now that's its been upgraded to 9.0 counts at 
 anything from 2 to 20 seconds per 5 second sample, the result is similar 
 with HPET, ACPI-fast and TSC.
 
 I also have physical boxes which new seem to drift quite substantially, 
 ntpd cannot keep up and as these boxes need to be able to report the 
 time relatively accurately, it is causing problems with log times and 
 such...
 
 Any suggestions most welcome!
 
 Thanks,
 J

I finally got a 9.0 generic build done today and I've been watching the
timekeeping on 3 systems and they're all doing just fine.  Two of the
systems are performing pretty much identically to how they did on 8.2;
the clock frequency correction calculated by ntpd differs by less than
1ppm.  On the other system the kernel timekeeping routines are now
choosing to use a different clock so I don't get a direct comparison of
the old vs new drift rate, but the drift is still reasonable  (100ppm
now, used to be around 88, on an old 300mhz MediaGx-based system).

I haven't had time yet to learn about the new eventtimer stuff in 9.0,
but I know you can get some info on the choices it made via sysctl
kern.eventtimer.  Before 9.0 I'd check sysctl kern.clockrate and vmstat
-i and make sure the chosen clock is interrupting at the right rate, but
now with the eventtimer stuff there's not an obvious correlation between
hz and profhz and stathz and any particular device's interrupt rate, at
least for some clock choices (on the old MediaGx system without ACPI or
HPET it seems to work more like it used to).

-- Ian


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: about thumper aka sun fire x4500

2012-01-18 Thread peter h
On Wednesday 18 January 2012 18.15, Adam McDougall wrote:
 On 01/17/12 17:09, Jeremy Chadwick wrote:
  On Tue, Jan 17, 2012 at 06:59:08PM +0100, peter h wrote:
  I have been beating on of these a few days, i have udes freebsd 9.0 and 8.2
  Both fails when i engage  10 disks, the system craches and messages :
  Hyper transport sync flood will get into the BIOS errorlog ( but nothing 
  will
  come to syslog since reboot is immediate)
 
  Using a zfs radz of 25 disks and typing zpool scrub will bring the 
  system down in seconds.
 
  Anyone using a x4500 that can comfirm that it works ? Or is this box 
  broken ?
 
 
 I've seen what is probably the same base issue but on multiple x4100m2 
 systems running FreeBSD 7 or 8 a few years ago.  For me the instant 
 reboot and HT sync flood error happened when I fetched a ~200mb file via 
 HTTP using an onboard intel nic and wrote it out to a simple zfs mirror 
 on 2 disks.  I may have tried the nvidia ethernet ports as an 
 alternative but that driver had its own issues at the time.  This was 
 never a problem with FFS instead of ZFS.  I could repeat it fairly 
 easily by running fetch in a loop (can't remember if writing the output 
 to disk was necessary to trigger it).  The workaround I found that 
 worked for me was to buy a cheap intel PCIE nic and use that instead of 
 the onboard ports.  If a zpool scrub triggers it for you, I doubt my 
 workaround will help but I wanted to relate my experience.

The problem i had was most likley the disc-io itself. It was always there 
whenever a larger number of discs was in motion.It was never there as 
violent networking ( i even used myri2000 to increase traffic, never a problem)

A scrub on the 20-or-so zpool was all that was needed, andn when rebooting 
the scrub continued and whoops - a new reboot.

Sometimes the bios reported not even 16G mem but 10.5 ( which also freebsd 
noticed)

Right now i am torturing the box with same load ( minus myri2000) and sunk-os,
i'll report if it does show simular problems.


 
  Given this above diagram, I'm sure you can figure out how flooding
  might occur.  :-)  I'm not sure what sync flood means (vs. I/O
  flooding).
 
 As I understand it, a sync flood is a purposeful reaction to an error 
 condition as somewhat of a last ditch effort to regain control over the 
 system (which ends up rebooting).  I'm pulling this out of my memory 
 from a few years ago.


 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
 

-- 
Peter Håkanson   

There's never money to do it right, but always money to do it
again ... and again ... and again ... and again.
( Det är billigare att göra rätt. Det är dyrt att laga fel. )
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Fighting with vnet / jails epair and so on

2012-01-18 Thread Denny Schierz
hi,

Am 18.01.2012 um 16:13 schrieb Shawn Webb:

 I've done a bit of research about vnet jails:
 http://archive.0xfeedface.org/blog/2011-11-21/lattera/freebsd-vnet-jail-admin-project

I know that tool too, but the host is an envoirenment with SSH only and nothing 
more and it should be work, without any dependencies. I think /etc/rc.d/jail 
isn't in this state compatible with vnet.

cu denny

signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Fighting with vnet / jails epair and so on

2012-01-18 Thread Philipp Huebner
Hi,

On 19/01/12 00:59, Denny Schierz wrote:
 ===
 
 # host: 
 jexec 2 ifconfig epair0b 192.168.1.2 netmask 255.255.255.0 up
 ifconfig: up: permission denied

I use 9.0.0 release for host and jail and a generic kernel with  OPTIONS
VIMAGE being the only change/addition.
No problem.

 
 
 # sysctl:
 
 security.jail.enforce_statfs: 2
 security.jail.mount_allowed: 0
 security.jail.chflags_allowed: 0
 security.jail.allow_raw_sockets: 1
 security.jail.sysvipc_allowed: 1

security.jail.allow_raw_sockets: 0
security.jail.sysvipc_allowed: 0

 security.jail.socket_unixiproute_only: 1
 security.jail.set_hostname_allowed: 1
 security.jail.jail_max_af_ips: 255
 security.jail.jailed: 0
 
 /etc/rc.conf:
 =
 jail_enable=YES
 jail_v2_enable=YES
 jail_list=
 jail_sysvipc_allow=YES
I don't have this line, not sure what it does either.

 
 #JAIL template
 jail_list=$jail_list template
 jail_template_name=template
 jail_template_hostname=template.CHANGED
 jail_template_devfs_enable=YES
 jail_template_rootdir=/jails/template
 jail_template_mount_enable=YES
 jail_template_fstab=/etc/jails/fstabs/template
 jail_template_vnet_enable=YES
 jail_template_devfs_ruleset=devfsrules_jail
  
 #network
 jail_template_exec_prestart0=ifconfig epair0 create
 jail_template_exec_prestart1=ifconfig bridge0 addm epair0a
 jail_template_exec_prestart2=ifconfig epair0a up
 jail_template_exec_earlypoststart0=ifconfig epair0b vnet template
 jail_template_exec_afterstart0=ifconfig lo0 127.0.0.1
 jail_template_exec_afterstart1=ifconfig epair0b 192.168.1.2 netmask 
 255.255.255.0 up
 jail_template_exec_afterstart2=route add default 130.83.160.62
 jail_template_exec_afterstart3=/bin/sh /etc/rc
  ^^^
The initscript runs /etc/rc already when the jail is created, this makes
it run a second time which messed things up for me.

When the initscript runs /etc/rc, all the scripts with NOJAIL are
skipped. For some reason, when running /etc/rc a second time through
this configuration, some daemons like cron were started a second time.

I now execute a custom /etc/rc.jail which runs a few init scripts
manually to configure networking and start a few daemons that don't come
up with the original run of /etc/rc.


 jail_template_exec_poststop0=ifconfig bridge0 deletem epair0a
 jail_template_exec_poststop1=ifconfig epair0a destroy

I am not doing this, because shortly after stopping a jail this would
give me a kernel panic.

If you comment those lines, the devices will stay where they are and
simply be re-used the next time you start the jail again. Works without
a problem for me.

Regards
Philipp
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


panic in bios32 ... stable/7

2012-01-18 Thread Sean Bruno
This probably applies to all releases, but for now I'm concentrating on
stable/7.

We have beta Dell r720 (12g) gear in the office and I suspect a broken
EFI wrapped BIOS thing here, but freebsd definitely panics on startup.  

OK boot -v
KDB: debugger backends: ddb
KDB: current backend: ddb
SMAP type=01 base= len=000a
SMAP type=01 base=0010 len=cd20
SMAP type=02 base=cd30 len=0002c000
SMAP type=03 base=cd32c000 len=0003f000
SMAP type=02 base=cd36b000 len=02c95000
SMAP type=02 base=e000 len=1000
SMAP type=02 base=fe00 len=0200
SMAP type=01 base=0001 len=000f3000
Physical memory use set to 2097152K
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.4-YAHOO-20111021 #0 ybsd_7@307778: Thu Dec 15 23:31:18 UTC 2011
sean...@x85.klab.corp.yahoo.com:/home/src/sys/i386/compile/NETBOOT i386
Preloaded elf kernel /boot/kernel at 0xa92c9000.
Preloaded mfs_root /boot/build.dsk at 0xa92c917c.
Calibrating clock(s) ... i8254 clock: 1193157 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2700021228 Hz
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz (2700.02-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x206d6  Family = 6  Model = 2d  Stepping = 6
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  
Features2=0x17bee3ffSSE3,b1,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,b17,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,b24,b25,XSAVE,b28
  AMD Features=0x2c10NX,Page1GB,RDTSCP,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant
  Cores per package: 16
  Logical CPUs per core: 2

Data TLB: 4 KB pages, 4-way set associative, 64 entries
L2 cache: 256 kbytes, 8-way associative, 64 bytes/line
real memory  = 2147483648 (2048 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x0960a000 - 0x7d995fff, 1949876224 bytes (476044 pages)
avail memory = 1942470656 (1852 MB)
Table 'FACP' at 0xcd35119c
Table 'APIC' at 0xcd350478
APIC: Found table at 0xcd350478
MP Configuration Table version 1.4 found at 0xa00f
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 32 ACPI ID 2: enabled
SMP: Added CPU 32 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 3: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 34 ACPI ID 4: enabled
SMP: Added CPU 34 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 5: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 36 ACPI ID 6: enabled
SMP: Added CPU 36 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 7: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 38 ACPI ID 8: enabled
SMP: Added CPU 38 (AP)
MADT: Found CPU APIC ID 8 ACPI ID 9: enabled
SMP: Added CPU 8 (AP)
MADT: Found CPU APIC ID 40 ACPI ID 10: enabled
SMP: Added CPU 40 (AP)
MADT: Found CPU APIC ID 10 ACPI ID 11: enabled
SMP: Added CPU 10 (AP)
MADT: Found CPU APIC ID 42 ACPI ID 12: enabled
SMP: Added CPU 42 (AP)
MADT: Found CPU APIC ID 12 ACPI ID 13: enabled
SMP: Added CPU 12 (AP)
MADT: Found CPU APIC ID 44 ACPI ID 14: enabled
SMP: Added CPU 44 (AP)
MADT: Found CPU APIC ID 14 ACPI ID 15: enabled
SMP: Added CPU 14 (AP)
MADT: Found CPU APIC ID 46 ACPI ID 16: enabled
SMP: Added CPU 46 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 17: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 33 ACPI ID 18: enabled
SMP: Added CPU 33 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 19: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 35 ACPI ID 20: enabled
SMP: Added CPU 35 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 21: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 37 ACPI ID 22: enabled
SMP: Added CPU 37 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 23: enabled
SMP: Added CPU 7 (AP)
MADT: Found CPU APIC ID 39 ACPI ID 24: enabled
SMP: Added CPU 39 (AP)
MADT: Found CPU APIC ID 9 ACPI ID 25: enabled
SMP: Added CPU 9 (AP)
MADT: Found CPU APIC ID 41 ACPI ID 26: enabled
SMP: Added CPU 41 (AP)
MADT: Found CPU APIC ID 11 ACPI ID 27: enabled
SMP: Added CPU 11 (AP)
MADT: Found CPU APIC ID 43 ACPI ID 28: enabled
SMP: Added CPU 43 (AP)
MADT: Found CPU APIC ID 13 ACPI ID 29: enabled
SMP: Added CPU 13 (AP)
MADT: Found CPU APIC ID 45 ACPI ID 30: enabled
SMP: Added CPU 45 (AP)
MADT: Found CPU APIC ID 15 ACPI ID 31: enabled
SMP: Added CPU 15 (AP)
MADT: Found CPU APIC ID 47 ACPI ID 32: enabled
SMP: Added CPU 47 (AP)
ACPI APIC Table: DELL   PE_SC3  
INTR: Adding local APIC 2 as a target
INTR: Adding local APIC 4 as a target
INTR: Adding 

Re: about thumper aka sun fire x4500

2012-01-18 Thread Markus Gebert
Hi Peter

On 18.01.2012, at 20:25, peter h wrote:

 On Wednesday 18 January 2012 18.15, Adam McDougall wrote:
 On 01/17/12 17:09, Jeremy Chadwick wrote:
 On Tue, Jan 17, 2012 at 06:59:08PM +0100, peter h wrote:
 I have been beating on of these a few days, i have udes freebsd 9.0 and 8.2
 Both fails when i engage  10 disks, the system craches and messages :
 Hyper transport sync flood will get into the BIOS errorlog ( but nothing 
 will
 come to syslog since reboot is immediate)
 
 Using a zfs radz of 25 disks and typing zpool scrub will bring the 
 system down in seconds.
 
 Anyone using a x4500 that can comfirm that it works ? Or is this box 
 broken ?
 
 
 I've seen what is probably the same base issue but on multiple x4100m2 
 systems running FreeBSD 7 or 8 a few years ago.  For me the instant 
 reboot and HT sync flood error happened when I fetched a ~200mb file via 
 HTTP using an onboard intel nic and wrote it out to a simple zfs mirror 
 on 2 disks.  I may have tried the nvidia ethernet ports as an 
 alternative but that driver had its own issues at the time.  This was 
 never a problem with FFS instead of ZFS.  I could repeat it fairly 
 easily by running fetch in a loop (can't remember if writing the output 
 to disk was necessary to trigger it).  The workaround I found that 
 worked for me was to buy a cheap intel PCIE nic and use that instead of 
 the onboard ports.  If a zpool scrub triggers it for you, I doubt my 
 workaround will help but I wanted to relate my experience.
 
 The problem i had was most likley the disc-io itself. It was always there 
 whenever a larger number of discs was in motion.It was never there as 
 violent networking ( i even used myri2000 to increase traffic, never a 
 problem)
 
 A scrub on the 20-or-so zpool was all that was needed, andn when rebooting 
 the scrub continued and whoops - a new reboot.
 
 Sometimes the bios reported not even 16G mem but 10.5 ( which also freebsd 
 noticed)
 
 Right now i am torturing the box with same load ( minus myri2000) and sunk-os,
 i'll report if it does show simular problems.
 
 
 
 Given this above diagram, I'm sure you can figure out how flooding
 might occur.  :-)  I'm not sure what sync flood means (vs. I/O
 flooding).
 
 As I understand it, a sync flood is a purposeful reaction to an error 
 condition as somewhat of a last ditch effort to regain control over the 
 system (which ends up rebooting).  I'm pulling this out of my memory 
 from a few years ago.

As Adam has pointed out, a sync flood is a way to signal an error condition on 
the hyper transport. As I understand it, it's used as a last resort when less 
fatal means of error communication are no longer possible because of a problem 
on the transport or a device attached to it. The transport will not recover 
from this state until it's reset. On Sun AMD systems a reboot is triggered 
immediately when a sync flood is detected. The fact that it happened is 
mentioned during POST, but it should also appear in the machine's error logs 
(IPMI/iLOM), so if you haven't done this already, it might be worth checking 
them. Maybe you'll find additional information there.

You should be able to disable the automatic reset on sync flood in your BIOS 
settings. We did this on our Sun X4200M2 machines when we experienced sync 
flood errors. It allowed the kernel to catch an MCE, panic and print out 
information about the MCE. This might help you get more information about the 
cause.

Our problems with the X4200M2 have some similarties with your case, though in 
our case high IO (i.e. zpool scrub) did not reliably (read: within minutes or 
hours) trigger the MCE/sync flood. If we put load on the zpool _and_ the 
network (em) we could trigger it easily. An other similarity: an other OS (in 
our case Linux), did not show the symptoms. Even other FreeBSD branches did not 
trigger the sync flood. You'll find the thread here:

http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057670.html

It's a rather long thread. Short version: If raid controller (mpt) interrupts 
were routed to the first cpu (cpu0) everything worked, if not, sync flood (or 
MCE) happened on heavy IO. It happens that Linux and even older and newer 
FreeBSD versions (7.x, 9.x) assigned different interrupt routes for mpt0 
compared to the FreeBSD 8.1 we were testing on. So what seemed like a bug of a 
specific FreeBSD version, because it didn't happen using other FreeBSD versions 
and Linux, turned out to be a hardware problem after all. IIRC a change in some 
hardware clock code caused an additional IRQ to be registered on boot (or one 
less), which reshuffled interrupt assignments compared to older FreeBSD 
versions we had used successfully on those machines. So we fixed it by setting 
a tunable which restored old clock behavior and thus old interrupt assignments.

It impossible to tell wether you have the same problem. But if you don't see 
any problems with other operating systems, maybe it's worth to 

Google Code-In 2011 is over; 56 tasks got completed for FreeBSD!

2012-01-18 Thread Wojciech A. Koszek

Hello,

(This is cross-posted message between current@, stable@ and hackers@; for
eventual discussion, please use hackers@ mailing list.)

I am glad to announce that we've successfully reached the end of Google
Code-In 2011 Contest!

FreeBSD participated first time, and in my personal opinion GCIN has proven
to be a big success. I want to thank all the participants for their time,
cooperation and dedication.

Here's the list of this years participants:

Alex Rucker, Andrey Sinitsyn, Anikan, Astha Sethi, Bebacz, 
Bharath Mohan, doctorkohaku, Eric Newberry, GarrettF,
Isabell Long (issyl0), mpaloski, Violet Lin (n00l3), Nagato Yuki,
Nathan, passstab, Reid Anderson, Robin, Roger, Rushil Paul,
Thomas Turney, Utkarsh Pant, Zacharias Mitzelos 

I would like to point out Isabell Long (issyl0) completed 13 tasks for us
and holds this years record.

Some other numbers...

We've had 19 mentors. I send special thanks to those who offered their help
in mentoring/administration, since accepting/reviewing/judging tasks has
proven to be challenging.

We've had 78 tasks published. 56 tasks got completed, leading to ~72%
successful completions.

1 task was claimed at the time of hitting the deadline, 10 tasks were
claimed, but never  finished, thus got reopened. 12 of tasks were never
claimed. List of tasks, together with their outcome (uploaded results)
are present here:

http://www.google-melange.com/gci/org/google/gci2011/freebsd

It would be my wish to have the work done in GCIN commited to FreeBSD with:

Submitted by:   Name email (Google Code-In 2011)

header or similar, clearly stating work comes from GCIN 2011.

The hardest expectations for mentors was short response time. For students
I think it was meeting FreeBSD's standards, however I'm positively surprised
by the quality of submitted work.

The complaint which I've heard is: Not enough coding tasks. We should fix
it next time, since most of the tasks were related with documentation and
outreach/promotion.

I think GCIN should become an integral part of the FreeBSD involvement in
promotion of the Open Source software.

Thank you.

-- 
Wojciech A. Koszek
wkos...@freebsd.czest.pl
http://FreeBSD.czest.pl/~wkoszek/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Fighting with vnet / jails epair and so on

2012-01-18 Thread Denny Schierz
hi,

Am 18.01.2012 um 23:21 schrieb Philipp Huebner:
 
 I use 9.0.0 release for host and jail and a generic kernel with  OPTIONS
 VIMAGE being the only change/addition.
 No problem.

so, how looks your rc.conf config ? Do you use vimage the tool? I can't use 
vimage (as I know) on sparc64.

What I did to get it working without /etc/rc.d/jail:

jail -c vnet jid=101 name=template host.hostname=template.example.com 
path=/jails/template/ persist
ifconfig epair0 create
ifconfig bridge0 addm epair0a
ifconfig epair0b vnet 101
jexec 101 ifconfig epair0b 192.168.1.2 netmask 255.255.255.0
jexec 101 route add default 192.168.1.1
ifconfig epair0a up


ping 192.168.1.2

64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.054 ms

inside the Jail I have only lo and epair0b and it works :-)

but even not from /etc/rc.conf and that is the problem.

cu denny

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org