Re: FB9-stable: bridge0 doesn't come up via rc *SOLVED*
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
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=8943 metric 0 mtu 1500 options=80099 ether CHANGED ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported media: Ethernet autoselect (1000baseT ) status: active bge1: flags=8802 metric 0 mtu 1500 options=8009b ether CHANGED ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported media: Ethernet autoselect (none) status: no carrier bge2: flags=8802 metric 0 mtu 1500 options=8009b ether CHANGED ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported media: Ethernet autoselect (none) status: no carrier bge3: flags=8802 metric 0 mtu 1500 options=8009b ether CHANGED ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported media: Ethernet autoselect (1000baseT ) status: active pflog0: flags=0<> metric 0 mtu 33152 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported ipfw0: flags=8801 metric 0 mtu 65536 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported lo0: flags=8049 metric 0 mtu 16384 options=3 ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported bridge0: flags=8843 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=143 ifmaxaddr 0 port 12 priority 128 path cost 2000 member: bge0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 55 epair0a: flags=8943 metric 0 mtu 1500 options=8 ether CHANGED ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported media: Ethernet 10Gbase-T (10Gbase-T ) status: active epair0b: flags=8842 metric 0 mtu 1500 options=8 ether CHANGED ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported media: Ethernet 10Gbase-T (10Gbase-T ) 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. uname -a: 9.0-STABLE FreeBSD 9.0-STABLE #0: Tue Jan 17 09:05:42 CET 2012 Also, some people say, I have to patch /etc/rc.d/jail (freeBSD 9-rc2) to get know the new "vnet2", other say, I don't need ... so Can anybody bring some light into the darkness of jails and vnet + rc? 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"
Re: about thumper aka sun fire x4500
On Tuesday 17 January 2012 22.52, Patrick M. Hausen wrote: > Hi, all, > > Am 17.01.2012 um 18:59 schrieb peter h : > > > 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
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 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=8943 metric 0 mtu > 1500 > options=80099 > ether CHANGED > ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported > media: Ethernet autoselect (1000baseT ) > status: active > bge1: flags=8802 metric 0 mtu 1500 > > options=8009b > ether CHANGED > ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported > media: Ethernet autoselect (none) > status: no carrier > bge2: flags=8802 metric 0 mtu 1500 > > options=8009b > ether CHANGED > ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported > media: Ethernet autoselect (none) > status: no carrier > bge3: flags=8802 metric 0 mtu 1500 > > options=8009b > ether CHANGED > ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported > media: Ethernet autoselect (1000baseT ) > status: active > pflog0: flags=0<> metric 0 mtu 33152 > ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported > ipfw0: flags=8801 metric 0 mtu 65536 > ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported > lo0: flags=8049 metric 0 mtu 16384 > options=3 > ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported > bridge0: flags=8843 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=143 > ifmaxaddr 0 port 12 priority 128 path cost 2000 > member: bge0 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 55 > epair0a: flags=8943 metric 0 > mtu 1500 > options=8 > ether CHANGED > ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported > media: Ethernet 10Gbase-T (10Gbase-T ) > status: active > epair0b: flags=8842 metric 0 mtu 1500 > options=8 > ether CHANGED > ifconfig: socket(AF_INET6, SOCK_DGRAM): Protocol not supported > media: Ethernet 10Gbase-T (10Gbase-T ) > 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. > > uname -a: > > 9.0-STABLE FreeBSD 9.0-STABLE #0: Tue Jan 17 09:05:42 CET 2012 > > Also, some people say, I have to patch /etc/rc.d/jail (freeBSD 9-rc2) to get > know the new "vnet2", other say, I don't need
Re: Fighting with vnet / jails epair and so on
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 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
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
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
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
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
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
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
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=0xbfebfbff Features2=0x17bee3ff,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,,,XSAVE,> AMD Features=0x2c10 AMD Features2=0x1 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: INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 8 as a target INTR: Adding local APIC 10 as a target INTR: Adding local APIC 12 as a target INTR: Adding local APIC 14 as a
Re: about thumper aka sun fire x4500
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 tel
Google Code-In 2011 is over; 56 tasks got completed for FreeBSD!
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 (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
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"
