KERN - mfi driver for Dell raid h200 on r210 servers
Hello lists,
I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server.
It ships with a SATA/SAS h200 RAID controller.
Sadly, the MFI driver doesn't seem to register for this card...
Find below the pciconf -lcvb
--
none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000
rev=0x02 hdr=0x00
vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
class = mass storage
subclass = SAS
bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled
bar [14] = type Memory, range 64, base 0xdf2b, size 65536, enabled
bar [1c] = type Memory, range 64, base 0xdf2c, size 262144, enabled
cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0
cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8)
cap 03[d0] = VPD
cap 05[a8] = MSI supports 1 message, 64 bit
cap 11[c0] = MSI-X supports 15 messages in map 0x14
--
I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119:
--
{0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, "Dell PERC H200 Integrated"},
--
Rebuilt the kernel, tried it on the server, still no luck recognizing
the RAID card.
As a last resort I'll be setting the drives to passthrough and using a
software RAID, but I'd much rather this worked out.
Note that mfi actually recognizes Dell's h700 and h800 cards.
Anyone managed to get the h200 card working yet ?
@hackers: please keep me cc'd, I'm not subscribed to this list.
Regards,
--
dfl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: KERN - mfi driver for Dell raid h200 on r210 servers
On 29 Jan 2011, at 23:24, "Bjoern A. Zeeb"
wrote:
> On Sat, 29 Jan 2011, Damien Fleuriot wrote:
>
>> Hello lists,
>>
>>
>> I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server.
>>
>> It ships with a SATA/SAS h200 RAID controller.
>>
>>
>> Sadly, the MFI driver doesn't seem to register for this card...
>>
>>
>> Find below the pciconf -lcvb
>>
>> --
>> none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000
>> rev=0x02 hdr=0x00
>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
>> class = mass storage
>> subclass = SAS
>> bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled
>> bar [14] = type Memory, range 64, base 0xdf2b, size 65536, enabled
>> bar [1c] = type Memory, range 64, base 0xdf2c, size 262144, enabled
>> cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0
>> cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8)
>> cap 03[d0] = VPD
>> cap 05[a8] = MSI supports 1 message, 64 bit
>> cap 11[c0] = MSI-X supports 15 messages in map 0x14
>> --
>>
>>
>> I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119:
>> --
>> {0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, "Dell PERC H200
>> Integrated"},
>> --
>
> It's 1f1d not 1f1e. I hope it was only a paste problem into email?
>
Nope no copy paste problem, I shall try again tomorrow with 1f1d then.
I found this line on the nginx site where the issue was being discussed.
Will post back my results asap.
>
>>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: KERN - mfi driver for Dell raid h200 on r210 servers
On 29 Jan 2011, at 20:26, Andrew Thompson wrote: > On 30 January 2011 06:20, Damien Fleuriot wrote: >> Hello lists, >> >> >> >> I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server. >> >> It ships with a SATA/SAS h200 RAID controller. >> > > This card may need the mps(4) driver which is only in HEAD at the moment. > > > Andrew Will give this a try if Bjoern's advice doesn't work for me, although I'll come back for directions on how to cleanly port mps on 8.x then.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: KERN - mfi driver for Dell raid h200 on r210 servers
On 29 Jan 2011, at 19:00, jhelf...@e-e.com wrote:
>> Hello lists,
>>
>>
>>
>> I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210
>> server.
>>
>> It ships with a SATA/SAS h200 RAID controller.
>>
>>
>> Sadly, the MFI driver doesn't seem to register for this card...
>>
>>
>> Find below the pciconf -lcvb
>>
>> --
>> none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000
>> rev=0x02 hdr=0x00
>>vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
>>class = mass storage
>>subclass = SAS
>>bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled
>>bar [14] = type Memory, range 64, base 0xdf2b, size 65536,
>> enabled
>>bar [1c] = type Memory, range 64, base 0xdf2c, size 262144,
>> enabled
>>cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0
>>cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8)
>>cap 03[d0] = VPD
>>cap 05[a8] = MSI supports 1 message, 64 bit
>>cap 11[c0] = MSI-X supports 15 messages in map 0x14
>> --
>>
>>
>> I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119:
>> --
>> {0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, "Dell PERC H200
>> Integrated"},
>> --
>>
>>
>> Rebuilt the kernel, tried it on the server, still no luck recognizing
>> the RAID card.
>>
>> As a last resort I'll be setting the drives to passthrough and using a
>> software RAID, but I'd much rather this worked out.
>>
>> Note that mfi actually recognizes Dell's h700 and h800 cards.
>>
>>
>>
>>
>> Anyone managed to get the h200 card working yet ?
>>
>>
>>
>>
>> @hackers: please keep me cc'd, I'm not subscribed to this list.
>>
>>
>>
>> Regards,
>>
>> --
>> dfl
>> ___
>> freebsd-sta...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>>
>>
> Hi Damien,
>
> I would suspect that you would need to compile the 'mpt' driver to get
> this to work. I found the same issue in the r310, however I already had
> mpt compiled in my kernel for another hardware platform.
>
> Good Luck!
> Jason
>
Hi,
I'm not sure, afaik mpt comes with GENERIC which is the kernel I put in the
mfsbsd image I tried to boot, and which failed to properly register any driver
for the h200 card.___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: KERN - mfi driver for Dell raid h200 on r210 servers
On 29 January 2011 23:24, Bjoern A. Zeeb wrote:
> On Sat, 29 Jan 2011, Damien Fleuriot wrote:
>
>> Hello lists,
>>
>>
>>
>> I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210
>> server.
>>
>> It ships with a SATA/SAS h200 RAID controller.
>>
>>
>> Sadly, the MFI driver doesn't seem to register for this card...
>>
>>
>> Find below the pciconf -lcvb
>>
>> --
>> none6@pci0:1:0:0: class=0x010700 card=0x1f1d1028 chip=0x00721000
>> rev=0x02 hdr=0x00
>> vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
>> class = mass storage
>> subclass = SAS
>> bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled
>> bar [14] = type Memory, range 64, base 0xdf2b, size 65536, enabled
>> bar [1c] = type Memory, range 64, base 0xdf2c, size 262144,
>> enabled
>> cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0
>> cap 10[68] = PCI-Express 2 endpoint max data 256(4096) link x8(x8)
>> cap 03[d0] = VPD
>> cap 05[a8] = MSI supports 1 message, 64 bit
>> cap 11[c0] = MSI-X supports 15 messages in map 0x14
>> --
>>
>>
>> I have added the following to /usr/src/sys/dev/mfi/mfi_pci.c at line 119:
>> --
>> {0x1000, 0x0072, 0x1028, 0x1f1e, MFI_FLAGS_GEN2, "Dell PERC H200
>> Integrated"},
>> --
>
> It's 1f1d not 1f1e. I hope it was only a paste problem into email?
>
Ok I've loaded the newly patched mfi.ko and booted a MFS image.
Here's the relevant snip from dmesg.run :
at
mfi0: port 0xfc00-0xfcff mem
0xdf2b-0xdf2b,0xdf2c-0xdf2f irq 16 at device 0.0 on
pci1
mfi0: Megaraid SAS driver Ver 3.00
mfi0: firmware stuck in state 0
mfi0: Firmware not in READY state, error 6
I'll have to try mps then, unless someone has an idea about this
"stuck in state 0" thing.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: KERN - mfi driver for Dell raid h200 on r210 servers
Indeed that is, the bsd install is aimed at a r210 EG server :) Is there any place one can get your image ? --- Fleuriot Damien On 30 Jan 2011, at 13:10, Ollivier Robert wrote: > I've "backported" the mps driver to 8.2 (I used cp -r :)) and I have > generated an img suited to the dedibox (that's what you are targeting, right? > :)) > > I tried to test it in vmware but I have a password issue right now. > > It is also a ZFSv28 image. > > Le 30 janv. 2011 à 01:56, Damien Fleuriot a écrit : > >> On 29 Jan 2011, at 20:26, Andrew Thompson wrote: >> >>> On 30 January 2011 06:20, Damien Fleuriot wrote: >>>> Hello lists, >>>> >>>> >>>> >>>> I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 >>>> server. >>>> >>>> It ships with a SATA/SAS h200 RAID controller. >>>> >>> >>> This card may need the mps(4) driver which is only in HEAD at the moment. >>> >>> >>> Andrew >> >> >> Will give this a try if Bjoern's advice doesn't work for me, although I'll >> come back for directions on how to cleanly port mps on 8.x >> then.___ >> freebsd-sta...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: harmless zfs warnings?
Hi Daniel, I'm afraid many people subscribed to stable are also hanging here and you may not have much more luck. If that is the case, you may wanna try freebsd-fs@ You will also want to: - increase geom's verbosity - provide your uname -a + zfs version - run dmesg -a for any additional info - show your zpool list - show your swapinfo for completion's sake - show your "mount" output, again for completion --- Fleuriot Damien On 4 Feb 2011, at 08:20, Daniel Braniss wrote: > I asked this on stable, and since there were no takers, trying my luck here. > > I see these messages: > ZFS WARNING: Unable to attach to gpt/r0/swap. > ZFS WARNING: Unable to attach to mfid0p3. > > I have 2 'disks' /dev/label/r0 and /dev/label/r5, > the r0 is gparted such: > =>34 1952448445 mfid0 GPT (931G) > 34 128 1 freebsd-boot (64K) > 162 4194304 2 freebsd-ufs (2.0G) > 4194466 100663296 3 freebsd-swap (48G) > 104857762 1847590717 4 freebsd-zfs (881G) > > when doing zpool import [z and or h] all is ok, except for > the above WARNINGs, are they harmless? > > thanks, >danny > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RELEASE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
Hi Devin, Thanks for sharing your work. The list strips non-text attachments so there isn't much to see at the moment though... --- Fleuriot Damien On 11 Feb 2011, at 04:53, Devin Teske wrote: > Hi All, > > I'd like to announce the release of a new script. A script that I've > developed for our field engineers that I'd like to share with the rest > of the world. > > http://druidbsd.sourceforge.net/download/host-setup.txt > > host-setup(1) is a dialog(1)-based utility (written in sh(1)) designed > to make configuring FreeBSD more efficient. > > We have this script configured to be run as root's initial login > immediately after "first-boot". The field engineer uses our custom > installer to install RELENG_8, and after the machine presents a login > prompt, they login with the pre-configured root password. After which > they are presented with this dialog (image attached: > host-setup.pub.png). > > The dialogs should all be intuitive, and I hope that you like my work. > I've worked very hard to make this utility smooth, robust, > fault-tolerant and even enjoyable to use. Not only that, but it helps > prevents mistakes that could arise in doing these steps by-hand (like > forgetting to unmount active NFS-mounts before executing "route flush"). > > Please give it a try and let me know what you think. > -- > Devin > > P.S. This is not a trivial script. ``More nuclear reactor than bike > shed'' ^_^ > > P.P.S. Should be backward compatible to RELENG_4. > > P.P.S. I know the screenshot says "host-setup.pub" -- that's only > because our in-house-only version has more functionality than the one > I'm releasing to the general public today (no functionality that anyone > in the public audience would ever care about though). > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RELEASE] host-setup(1): a dialog(1)-based utility for configuring FreeBSD
On 2/11/11 4:53 AM, Devin Teske wrote: > Hi All, > > I'd like to announce the release of a new script. A script that I've > developed for our field engineers that I'd like to share with the rest > of the world. > > http://druidbsd.sourceforge.net/download/host-setup.txt > > host-setup(1) is a dialog(1)-based utility (written in sh(1)) designed > to make configuring FreeBSD more efficient. > > We have this script configured to be run as root's initial login > immediately after "first-boot". The field engineer uses our custom > installer to install RELENG_8, and after the machine presents a login > prompt, they login with the pre-configured root password. After which > they are presented with this dialog (image attached: > host-setup.pub.png). > > The dialogs should all be intuitive, and I hope that you like my work. > I've worked very hard to make this utility smooth, robust, > fault-tolerant and even enjoyable to use. Not only that, but it helps > prevents mistakes that could arise in doing these steps by-hand (like > forgetting to unmount active NFS-mounts before executing "route flush"). > > Please give it a try and let me know what you think. > -- > Devin > > P.S. This is not a trivial script. ``More nuclear reactor than bike > shed'' ^_^ > > P.P.S. Should be backward compatible to RELENG_4. > > P.P.S. I know the screenshot says "host-setup.pub" -- that's only > because our in-house-only version has more functionality than the one > I'm releasing to the general public today (no functionality that anyone > in the public audience would ever care about though). > Hi Devin, Thanks for sharing, but I'm afraid the list automagically strips away non-text attachments, you'll have to upload your screenshots somewhere :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: buildkernel error
Rebuild the world first, then the kernel :) --- Fleuriot Damien On 22 Feb 2011, at 08:30, gnehzuil wrote: > Hi all, > > I updated my kernel source code and try to make a new kernel using make > buildkernel command. But I got an error as follow: > > > :> hack.c > cc -shared -nostdlib hack.c -o hack.So > rm -f hack.c > MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 > -msoft-float -ffreestanding -fstack-protector -Werror vers.c > linking kernel.debug > ld:/usr/src/sys/conf/ldscript.i386:66: syntax error > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/MYKERNEL. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > gnehzuil-freebsd# > -- > > I run a freebsd OS in virtualbox. > > > Best regards, > lz > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
LAGG - interface comes up but no laggports
Hello list, I've been having this odd problem with a lagg interface for some time now... I have 2 boxes at home, a NAS running 8.1-RELEASE and a win7 workstation. I recently purchased 2 intel dual port NICs and gifted my machines one each. My problem is that on the FreeBSD box, the lagg interface is created correctly, but the NIC's ports aren't added to it. loader.conf --- # Up a bit our intel cards parameters hw.em.txd=4096 hw.em.xxd=4096 hw.em.tx_int_delay=512 hw.em.rx_int_delay=512 hw.em.tx_abs_int_delay=1024 hw.em.rx_abs_int_delay=1024 rc.conf --- # LINK AGGREG ifconfig_em0="polling mtu 9014 up" ifconfig_em1="polling mtu 9014 up" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport em0 laggport em1" ipv4_addrs_lagg0="192.168.1.3/29" ifconfig_lagg0="inet6 fe80::3/64" lagg0 interface after boot --- lagg0: flags=8843 metric 0 mtu 1500 ether 00:00:00:00:00:00 inet6 fe80::3%lagg0 prefixlen 64 scopeid 0x5 inet 192.168.1.3 netmask 0xfff8 broadcast 192.168.1.7 nd6 options=3 media: Ethernet autoselect status: no carrier laggproto failover lagg0 interface after "ifconfig lagg0 laggport em0 laggport em1" manually --- lagg0: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e6 inet6 fe80::3%lagg0 prefixlen 64 scopeid 0x5 inet 192.168.1.3 netmask 0xfff8 broadcast 192.168.1.7 nd6 options=3 media: Ethernet autoselect status: active laggproto failover laggport: em1 flags=0<> laggport: em0 flags=5 pciconf -lcvb --- em0@pci0:1:0:0: class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfe7a, size 131072, enabled bar [14] = type Memory, range 32, base 0xfe78, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xa880, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) em1@pci0:1:0:1: class=0x02 card=0x135e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfe7e, size 131072, enabled bar [14] = type Memory, range 32, base 0xfe7c, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xac00, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) Now, this is not such a BIG concern because this lagg is only used between my win7 workstation and the NAS. What bothers me is that we have other PF boxes at work, which I also configured, and for which I do not have this problem. I should note that this is a direct connection, there is no switch between the 2 machines. Also, notice I set a 9014 MTU on my physical ports: em0: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e6 inet6 fe80::215:17ff:fe37:17e6%em0 prefixlen 64 scopeid 0x1 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e7 inet6 fe80::215:17ff:fe37:17e7%em1 prefixlen 64 scopeid 0x2 nd6 options=3 media: Ethernet autoselect status: no carrier Yet the lagg interface itself reports a MTU of 1500. Anyone ever run into this problem before ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: LAGG - interface comes up but no laggports
On 2/22/11 1:18 PM, Bernhard Schmidt wrote: > On Tuesday, February 22, 2011 12:31:34 Damien Fleuriot wrote: >> rc.conf >> --- >> # LINK AGGREG >> ifconfig_lagg0="laggproto failover laggport em0 laggport em1" >> ipv4_addrs_lagg0="192.168.1.3/29" >> ifconfig_lagg0="inet6 fe80::3/64" > > You are overwriting the variable, you have to use some alternative or > move everything into one statement. > Good call, it now works correctly: lagg0: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e6 inet6 fe80::215:17ff:fe37:17e6%lagg0 prefixlen 64 scopeid 0x5 inet 192.168.1.3 netmask 0xfff8 broadcast 192.168.1.7 nd6 options=3 media: Ethernet autoselect status: active laggproto failover laggport: em1 flags=0<> laggport: em0 flags=5 You'll notice that using ipv6_addrs didn't work, as the interface is using an automatic address instead of fe80::3/64 which I tried to set. I suppose I could use the crontab for this, @reboot ifconfig lagg0 inet6 fe80::3/64 , or perhaps rc.local Thanks for the help everyone, this was becoming frustrating. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: LAGG - interface comes up but no laggports
On 2/22/11 1:51 PM, Ryan Stone wrote: > On Tue, Feb 22, 2011 at 6:31 AM, Damien Fleuriot wrote: >> ifconfig_lagg0="laggproto failover laggport em0 laggport em1" >> ipv4_addrs_lagg0="192.168.1.3/29" >> ifconfig_lagg0="inet6 fe80::3/64" > > You're setting ifconfig_lagg0 twice, so the first setting is being > discarded. Off-hand I'm not sure how you're supposed to configure > ipv6 addresses. There's nothing in the man page about an > ipv6_addrs_lagg0 variable but that would be the obvious thing to try, ipv6_addrs_XXX doesn't do the trick, however this one does: ipv6_ifconfig_lagg0="fe80::3/64" lagg0: flags=8843 metric 0 mtu 9014 options=19b ether 00:15:17:37:17:e6 inet6 fe80::215:17ff:fe37:17e6%lagg0 prefixlen 64 scopeid 0x5 inet 192.168.1.3 netmask 0xfff8 broadcast 192.168.1.7 inet6 fe80::3%lagg0 prefixlen 64 scopeid 0x5 nd6 options=3 media: Ethernet autoselect status: active laggproto failover laggport: em1 flags=0<> laggport: em0 flags=5 For a reason that eludes me, the interface still insists on getting an automatic link local address, but I'll look into this ;) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: LAGG - interface comes up but no laggports
On 2/22/11 2:27 PM, Bernhard Schmidt wrote: > On Tuesday, February 22, 2011 14:17:46 Damien Fleuriot wrote: >> On 2/22/11 1:18 PM, Bernhard Schmidt wrote: >>> On Tuesday, February 22, 2011 12:31:34 Damien Fleuriot wrote: >>>> rc.conf >>>> --- >>>> # LINK AGGREG >>>> ifconfig_lagg0="laggproto failover laggport em0 laggport em1" >>>> ipv4_addrs_lagg0="192.168.1.3/29" >>>> ifconfig_lagg0="inet6 fe80::3/64" >>> >>> You are overwriting the variable, you have to use some alternative >>> or move everything into one statement. >> >> Good call, it now works correctly: >> lagg0: flags=8843 metric 0 >> mtu 9014 >> options=19b >> ether 00:15:17:37:17:e6 >> inet6 fe80::215:17ff:fe37:17e6%lagg0 prefixlen 64 scopeid 0x5 >> inet 192.168.1.3 netmask 0xfff8 broadcast 192.168.1.7 >> nd6 options=3 >> media: Ethernet autoselect >> status: active >> laggproto failover >> laggport: em1 flags=0<> >> laggport: em0 flags=5 >> >> >> You'll notice that using ipv6_addrs didn't work, as the interface is >> using an automatic address instead of fe80::3/64 which I tried to >> set. >> >> I suppose I could use the crontab for this, @reboot ifconfig lagg0 >> inet6 fe80::3/64 , or perhaps rc.local > > I'm using ipv6_ifconfig_XXX0[_aliasX] to assign IPv6 addresses, might be > worth a try? I don't see ipv6_addrs_XXX0 to be even defined somewhere. > Indeed I was just tryng that and waiting for the reboot, works fine. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: listing all modules compiled into a kernel instance
On 3/1/11 5:40 AM, Carl wrote: > Kernel drivers can be (and in at least one case are) compiled into the > kernel but are not reported when queried for, at least not in a way that > I am aware of. For example, the ucom driver is present in the GENERIC > kernel in this way. My expectation was that "kldstat -v" would list it, > if present, but it does not. A design flaw? > > # ls /boot/kernel/ucom.ko > /boot/kernel/ucom.ko > # grep ucom /usr/src/sys/i386/conf/GENERIC > # kldstat -v | grep ucom > # kldload ucom.ko > # tail -n 1 /var/log/messages > Feb 28 18:18:15 xx kernel: interface ucom.1 already present in the > KLD 'kernel'! > > How does one query an existing kernel for *all* compiled-in modules? > > I'm using FreeBSD-8.1-RELEASE-amd64/i386. > > Carl / K0802647 > Well AFAIK kldstat -v should return them all... Also, as a side note to your question, find below an excerpt from ucom's man page: SYNOPSIS To compile this driver into the kernel, place the following line in your kernel configuration file: device ucom Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): ucom_load="YES" So indeed if you want it statically in the kernel, you need to add "device ucom" Have you tried doing that, building again then querying again with kldstat -v ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: listing all modules compiled into a kernel instance
On 3/1/11 12:20 PM, Maxim Khitrov wrote: > On Mon, Feb 28, 2011 at 11:40 PM, Carl wrote: >> Kernel drivers can be (and in at least one case are) compiled into the >> kernel but are not reported when queried for, at least not in a way that I >> am aware of. For example, the ucom driver is present in the GENERIC kernel >> in this way. My expectation was that "kldstat -v" would list it, if present, >> but it does not. A design flaw? >> >> # ls /boot/kernel/ucom.ko >> /boot/kernel/ucom.ko >> # grep ucom /usr/src/sys/i386/conf/GENERIC >> # kldstat -v | grep ucom >> # kldload ucom.ko >> # tail -n 1 /var/log/messages >> Feb 28 18:18:15 xx kernel: interface ucom.1 already present in the KLD >> 'kernel'! >> >> How does one query an existing kernel for *all* compiled-in modules? >> >> I'm using FreeBSD-8.1-RELEASE-amd64/i386. >> >> Carl / K0802647 > > kldstat provides information about components that were loaded > dynamically. If your kernel was built with INCLUDE_CONFIG_FILE option > (enabled by default in GENERIC), then you can see the static > components using: > > config -x /boot/kernel/kernel > > See config(8) for more details. > > - Max kldstat also shows statically compiled modules, example below. Here's my kldstat: # kldstat Id Refs AddressSize Name 1 16 0x8010 91f9f8 kernel 21 0x80a2 bbd8 geom_label.ko 31 0x80a2c000 21058geom_mirror.ko 41 0x80a4e000 f078 aio.ko 51 0x80c22000 104d42 zfs.ko 61 0x80d27000 f217 krpc.ko 71 0x80d37000 1a15 opensolaris.ko Now, looking for my network card: # kldstat -v |grep bce 65 pci/bce 64 bce/miibus ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: New Boot-Loader
On 3/28/11 6:48 AM, Devin Teske wrote:
> Hi fellow hackers,
>
> I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel
> that the existing options in the boot-loader menu today can be whittled down
> significantly with a stateful menu system rather than a single-action item
> menu system.
>
> In designing the new menu, I'd like to get your opinions. From old:
>
> FreeBSD 8.1-RELEASE: twitpic.com/4e485w
>
> to new:
>
> Replacement Boot-Loader: twitpic.com/4e46ol
>
> NOTE: The final release will have a single-user mode option.
>
> The new menu allows for more flexibility as selecting options 2 ("Boot
> Verbose") or 3 ("ACPI Support") independently toggles the status, updates the
> menu item, and redisplays the menu -- ever-waiting until the user ultimately
> presses ENTER, "1", or escapes to the prompt and types "boot". Thus, one
> could potentially launch single-user mode with verbosity on and ACPI disabled
> (if one so desired).
>
> In addition, I really tried to capture the essence of the new logo (spent
> months off-and-on using different conversion programs with different inputs).
> In the end, I found text-image.com produced the best result. I used the
> official freebsd.org/logo.html Standard Logo (black and white), cropped (to
> 122x123) and converted to jpeg with white background. I used an "Image Width"
> of 45 in their "Convert into ASCII" program available here:
> text-image.com/convert/ascii.html
>
> I would be distributing this as an installable package (perhaps in the ports
> tree if it gains popularity).
I like the new looks, thanks for your efforts :)
I also like Paul's idea of tying the actions (single, verbose) to
letters instead of numbers.
As for the comment about this "new" look not being modern enough, to be
honest I for one could care less.
I'm using servers, when I see this loader this usually means there's a
problem or I'm anticipating one.
So it looking fancy isn't really my top priority, I'd rather it be
functional and well thought-out.
Thanks again for your work Devin :)
--
dfl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ifconfig output: ipv4 netmask format
On 4/8/11 5:40 PM, Sergey Vinogradov wrote: > On 08.04.2011 19:23, Warner Losh wrote: >> >> On Apr 8, 2011, at 6:08 AM, Sergey Vinogradov wrote: >> >>> Hi, hackers. >>> I have a question: why ipv4 netmask is displayed by ifconfig in hex >>> format? Isn't dot-decimal notation more human-readable? Will the >>> attached patch break something in the very bad way? >> >> This is a gratuitous change that would break scripts. Hex has been >> used for a very long time, and most people know how to cope. >> >> If we really wanted to make it human readable, we'd output 10.2.3.4/24 >> >> Warner > So, maybe, while following the POLA, we should add an option, as Daniel > mentioned above? To output the CIDR? > Seconded :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ifconfig output: ipv4 netmask format
On 4/9/11 7:33 AM, Garrett Cooper wrote: > > Although I see the value of your and Sergey's argument, the problem is > that it may cause unexpected breakage for other third parties that > depend on a particular behavior in FreeBSD as Bjoern and others have > suggested; I have a script at least that does properly parse out the > hex output in order to set IPs properly with ipmitool, and I would be > perturbed to have to hack around this further in my script. > > Thanks, > -Garrett > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" If the proposed change was made an option via a knob as has been suggested, that would leave your script unscathed. One might or might not like the option, and then choose to use it or disregard it. Given that one can configure their interfaces by giving a CIDR notation (like: ifconfig re0 inet 192.168.0.1/24) , it makes sense that one should be able to output the CIDR notation as well. I for one see absolutely no valid reason why the change should be rejected if it doesn't change ifconfig's default behaviour and doesn't cause any regression ? A valid reason would be: nobody wants it. But then, some people do seem to want it. I would like this option really, would prolly alias it while I'm at it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
DEBUG - analysing core dumps
Hello list, We've got these boxes at work running FreeBSD 8.1-STABLE amd64 and serving as firewalls and openvpn gateways. We use CARP interfaces to provide an active-passive fault tolerant system. Today, we received a nagios alert from the master box saying it's rsyslogd process had crashed. I logged on to it and tried to relaunch it, to no avail: pid 2303 (rsyslogd), uid 0: exited on signal 11 (core dumped) I would like advice on how to debug the output from the core dump. This is what I get from gdb: # gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd". (gdb) core rsyslogd.core Core was generated by `rsyslogd'. Program terminated with signal 11, Segmentation fault. #0 0x004258ec in ?? () Sadly, getting a backtrace with "bt" gives me more lines with "??", which is totally not helpful: [SNIP] #13 0x7f1f9d70 in ?? () #14 0x in ?? () #15 0x6f70732f7261762f in ?? () #16 0x6c737973722f6c6f in ?? () #17 0x5f6e70766f2f676f in ?? () #18 0x746174732e676f6c in ?? () #19 0x0065 in ?? () #20 0x in ?? () [SNIP] I am not sure what steps I should follow to get more information ? Also, I believe that often, core dumps with signal 11 = RAM problems and I would like a confirmation here. I am concerned because rsyslogd is the only process that crashes in this way, even after I rebooted the firewall. Thanks for your input :) -- dfl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: DEBUG - analysing core dumps
On 5/25/11 7:10 PM, Garrett Cooper wrote: > On Wed, May 25, 2011 at 9:36 AM, Damien Fleuriot wrote: >> Hello list, >> >> >> >> We've got these boxes at work running FreeBSD 8.1-STABLE amd64 and >> serving as firewalls and openvpn gateways. >> >> We use CARP interfaces to provide an active-passive fault tolerant system. >> >> >> Today, we received a nagios alert from the master box saying it's >> rsyslogd process had crashed. >> >> I logged on to it and tried to relaunch it, to no avail: >> pid 2303 (rsyslogd), uid 0: exited on signal 11 (core dumped) >> >> >> >> >> I would like advice on how to debug the output from the core dump. >> >> This is what I get from gdb: >> >> # gdb >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd". >> (gdb) core rsyslogd.core >> Core was generated by `rsyslogd'. >> Program terminated with signal 11, Segmentation fault. >> #0 0x004258ec in ?? () >> >> >> >> >> Sadly, getting a backtrace with "bt" gives me more lines with "??", >> which is totally not helpful: >> [SNIP] >> #13 0x7f1f9d70 in ?? () >> #14 0x in ?? () >> #15 0x6f70732f7261762f in ?? () >> #16 0x6c737973722f6c6f in ?? () >> #17 0x5f6e70766f2f676f in ?? () >> #18 0x746174732e676f6c in ?? () >> #19 0x0065 in ?? () >> #20 0x in ?? () >> [SNIP] >> >> I am not sure what steps I should follow to get more information ? >> >> >> >> Also, I believe that often, core dumps with signal 11 = RAM problems and >> I would like a confirmation here. >> >> I am concerned because rsyslogd is the only process that crashes in this >> way, even after I rebooted the firewall. > > Rebuild and reinstall rsyslogd with debug symbols and see if you > can get a reasonable stack trace. Something else to try before that to > narrow down the problem section of code is ktrace/kdump it, or truss > it, and see if it's trying to open/read from a file and failing. > Thanks, > -Garrett Thanks everyone for your answers, I'll recompile with DEBUG and obtain a new core dump. I'll also investigate the possibility of corrupted spool files and post the resolution here :) -- dfl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: DEBUG - analysing core dumps
On 26 May 2011 09:51, Damien Fleuriot wrote: > > > On 5/25/11 7:10 PM, Garrett Cooper wrote: >> On Wed, May 25, 2011 at 9:36 AM, Damien Fleuriot wrote: >>> Hello list, >>> >>> >>> >>> We've got these boxes at work running FreeBSD 8.1-STABLE amd64 and >>> serving as firewalls and openvpn gateways. >>> >>> We use CARP interfaces to provide an active-passive fault tolerant system. >>> >>> >>> Today, we received a nagios alert from the master box saying it's >>> rsyslogd process had crashed. >>> >>> I logged on to it and tried to relaunch it, to no avail: >>> pid 2303 (rsyslogd), uid 0: exited on signal 11 (core dumped) >>> >>> >>> >>> >>> I would like advice on how to debug the output from the core dump. >>> >>> This is what I get from gdb: >>> >>> # gdb >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and you are >>> welcome to change it and/or distribute copies of it under certain >>> conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for details. >>> This GDB was configured as "amd64-marcel-freebsd". >>> (gdb) core rsyslogd.core >>> Core was generated by `rsyslogd'. >>> Program terminated with signal 11, Segmentation fault. >>> #0 0x004258ec in ?? () >>> >>> >>> >>> >>> Sadly, getting a backtrace with "bt" gives me more lines with "??", >>> which is totally not helpful: >>> [SNIP] >>> #13 0x7f1f9d70 in ?? () >>> #14 0x in ?? () >>> #15 0x6f70732f7261762f in ?? () >>> #16 0x6c737973722f6c6f in ?? () >>> #17 0x5f6e70766f2f676f in ?? () >>> #18 0x746174732e676f6c in ?? () >>> #19 0x0065 in ?? () >>> #20 0x in ?? () >>> [SNIP] >>> >>> I am not sure what steps I should follow to get more information ? >>> >>> >>> >>> Also, I believe that often, core dumps with signal 11 = RAM problems and >>> I would like a confirmation here. >>> >>> I am concerned because rsyslogd is the only process that crashes in this >>> way, even after I rebooted the firewall. >> >> Rebuild and reinstall rsyslogd with debug symbols and see if you >> can get a reasonable stack trace. Something else to try before that to >> narrow down the problem section of code is ktrace/kdump it, or truss >> it, and see if it's trying to open/read from a file and failing. >> Thanks, >> -Garrett > > > > > Thanks everyone for your answers, I'll recompile with DEBUG and obtain a > new core dump. > > I'll also investigate the possibility of corrupted spool files and post > the resolution here :) > > > -- > dfl > Turns out that after rebuilding rsyslog4-relp with -DWITH_DEBUG , the new daemon works just fine and doesn't sig11 anymore. Odd, but well, solves my problem. I will upgrade it on all the other boxes then. Thanks for the help guys -- dfl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Add user to croosworld DESTDIR
On 10/4/11 5:06 PM, rank1see...@gmail.com wrote: > When I wana add user into DESTDIR, I chroot into it. > However, in this case, DESTDIR has an arch of amd64, while running machine is > i386. > So that isn't an option as all execute attempts would fail(Exec format error). > > I've tried with pw's '-V etcdir' flag and it did created user in amd64 > DESTDIR, BUT without home dir! > > I've found this: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2108497+0+archive/2001/freebsd-questions/20011028.freebsd-questions > > I did however, managed to writte wrapper function, which created home and > mail layout, as would original FreeBSD installation. > BUT, all $DESTDIR/home/$USER dirs, are owned by 0:0 and I can't find a way to > chown it to DESTDIR user. > > That LAST step is all I need. > Anyone has any idea? > Grep the newly added user's UID/GID from $DESTDIR/etc/passwd , chown to these, should work even if they don't exist on your original system. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Clustering server in freebsd
On 10/10/11 9:31 PM, elman wrote: > Dear all > > I have plan to cluster server with freebsd 8.2 for mailserver. But I'm > confusing with the software for clustering. Do you have a reference for me, > or do you have blog and I can see your blog for reference to create > clustering with freebsd. > > Thanks hacker > Best regards. > Mr. L > Powered by Telkomsel BlackBerry® > Your question is very vague. - what goal do you want to achieve ? - do you want a redundant mail system in case one of your servers goes down ? - do you want a load balanced system to distribute the load (incurring a degraded service if a server goes down) ? - what do you mean by "mailserver", is that for outbound and inbound email (SMTP), for users to grab their email (POP,IMAP), or both ? Basically you're giving us a *means* (clustered servers) to an *end* that we do not know/understand. You've thus had 2 responses so far which might or might not have been helpful because nobody knows what you're trying to do ;) If you want meaningful answers, you'll have to be much more specific. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysctl description spillover and also setting the sysctl ?
On 11/30/11 7:48 PM, Jason Hellenthal wrote: > > > On Wed, Nov 30, 2011 at 11:52:46AM -0500, John Baldwin wrote: >> On Friday, November 25, 2011 2:36:30 am Jason Hellenthal wrote: >>> >>> Found a troubling result of the following and figured someone might want to >> take a look. >>> >>> Pay close attention to the output and behavior. >>> >>> sysctl net.inet.udp.blackhole=0 >>> sysctl net.inet.udp.blackhole >>> sysctl -d net.inet.udp.blackhole=1 >>> sysctl net.inet.udp.blackhole >>> >>> >>> Is this expected ? should it not just display the description instead of >> adjusting ? as well not display the description like it is adjusting the >> description too ? >> >> Hah, cute. It should probably fail with an error if you do something like >> that, yes. >> > > Yeah thats what I thought about it to but the more I thought about it, if it > just displayed the values changing instead of the description when =N is > supplied I think that would be acceptable to. 0 -> 1 in this case. Or > possibly sys.oid: 0 -> 1 # since sysctl.conf(5) also takes > comments like that. > > Not really thats something at the top of the list for fixes though. Low > fruit. Food for thought. > Perhaps you would kindly provide a patch for this ? I might have a look at it if nobody does, sounds trivial enough that I might be able to handle it ;) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysctl description spillover and also setting the sysctl ?
On 11/30/11 7:48 PM, Jason Hellenthal wrote:
>
>
> On Wed, Nov 30, 2011 at 11:52:46AM -0500, John Baldwin wrote:
>> On Friday, November 25, 2011 2:36:30 am Jason Hellenthal wrote:
>>>
>>> Found a troubling result of the following and figured someone might want to
>> take a look.
>>>
>>> Pay close attention to the output and behavior.
>>>
>>> sysctl net.inet.udp.blackhole=0
>>> sysctl net.inet.udp.blackhole
>>> sysctl -d net.inet.udp.blackhole=1
>>> sysctl net.inet.udp.blackhole
>>>
>>>
>>> Is this expected ? should it not just display the description instead of
>> adjusting ? as well not display the description like it is adjusting the
>> description too ?
>>
>> Hah, cute. It should probably fail with an error if you do something like
>> that, yes.
>>
>
> Yeah thats what I thought about it to but the more I thought about it, if it
> just displayed the values changing instead of the description when =N is
> supplied I think that would be acceptable to. 0 -> 1 in this case. Or
> possibly sys.oid: 0 -> 1 # since sysctl.conf(5) also takes
> comments like that.
>
> Not really thats something at the top of the list for fixes though. Low
> fruit. Food for thought.
>
Ok so I'm totally not a dev, don't take my findings for granted, but:
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/src/sbin/sysctl/sysctl -d net.inet.udp.blackhole=1
Breakpoint 5, show_var (oid=0x7fffe1d0, nlen=4) at
/usr/src/sbin/sysctl/sysctl.c:549
549 {
(gdb) s
562 bzero(buf, BUFSIZ);
(gdb) s
563 bzero(name, BUFSIZ);
(gdb) s
564 qoid[0] = 0;
(gdb) s
565 memcpy(qoid + 2, oid, nlen * sizeof(int));
(gdb) s
567 qoid[1] = 1;
(gdb) s
568 j = sizeof(name);
(gdb) s
569 i = sysctl(qoid, nlen + 2, name, &j, 0, 0);
(gdb) s
570 if (i || !j)
(gdb) s
573 if (Nflag) {
(gdb) s
578 if (eflag)
(gdb) s
581 sep = ": ";
(gdb) s
583 if (dflag) {/* just print description */
(gdb) s
584 qoid[1] = 5;
(gdb) s
585 j = sizeof(buf);
(gdb) s
586 i = sysctl(qoid, nlen + 2, buf, &j, 0, 0);
(gdb) s
587 if (!nflag)
(gdb) s
588 printf("%s%s", name, sep);
(gdb) s
net.inet.udp.blackhole:
589 printf("%s", buf);
(gdb) s
Do not send port unreachables for refused connects
590 return (0);
(gdb) s
719 }
At this point, we have shown the description and should exit.
Instead, we're calling parse() again ?
(gdb) s
parse (string=0x7fffee07 "net.inet.udp.blackhole") at
/usr/src/sbin/sysctl/sysctl.c:299
299 if (sysctl(mib, len, 0, 0, newval, newsize) == -1) {
(gdb) s
318 if (!bflag)
(gdb) s
319 printf(" -> ");
(gdb) s
-> 320 i = nflag;
(gdb) s
321 nflag = 1;
(gdb) s
322 j = show_var(mib, len);
(gdb) s
Breakpoint 5, show_var (oid=0x7fffe1d0, nlen=4) at
/usr/src/sbin/sysctl/sysctl.c:549
549 {
(gdb) s
562 bzero(buf, BUFSIZ);
(gdb) s
563 bzero(name, BUFSIZ);
(gdb) s
564 qoid[0] = 0;
(gdb) s
565 memcpy(qoid + 2, oid, nlen * sizeof(int));
(gdb) s
567 qoid[1] = 1;
(gdb) s
568 j = sizeof(name);
(gdb) s
569 i = sysctl(qoid, nlen + 2, name, &j, 0, 0);
(gdb) s
570 if (i || !j)
(gdb) s
573 if (Nflag) {
(gdb) s
578 if (eflag)
(gdb) s
581 sep = ": ";
(gdb) s
583 if (dflag) {/* just print description */
(gdb) s
584 qoid[1] = 5;
(gdb) s
585 j = sizeof(buf);
(gdb) s
586 i = sysctl(qoid, nlen + 2, buf, &j, 0, 0);
(gdb) s
587 if (!nflag)
(gdb) s
589 printf("%s", buf);
(gdb) s
Do not send port unreachables for refused connects
590 return (0);
(gdb) s
719 }
(gdb) s
parse (string=0x7fffee07 "net.inet.udp.blackhole") at
/usr/src/sbin/sysctl/sysctl.c:323
323 if (!j && !bflag)
(gdb) s
324 putchar('\n');
(gdb) s
__sputc (_c=10, _p=0x80085a810) at stdio.h:457
457 if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c
!= '\n'))
(gdb) s
460 return (__swbuf(_c, _p));
(gdb) s
461 }
(gdb) s
parse (string=0x7fffee07 "net.inet.udp.blackhole") at
/usr/src/sbin/sysctl/sysctl.c:325
325 nflag = i;
(gdb) s
327 }
(gdb) s
main (argc=0, argv=0x7fffeb48) at /usr/src/sbin/sysctl/sysctl.c:154
154 while (argc-- > 0)
(gdb) s
156 exit(warncount);
(gdb) s
Program exited normally.
I think that the issue here is that sysctl continues being run after
displaying the descr
Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
On 12/1/11 11:44 AM, Steven Hartland wrote: > - Original Message - From: "Jason Hellenthal" > >> This goes along with the thoughts I had about 4 months ago tending to >> some >> zfs statistics as well top showing greater than 100% actual CPU usage. >> This >> is a big pet peave of mine. Its like saying you ate 134% of a bannanna >> when >> in all reallity it is impossible. You can never have more than 100% >> usage of >> anything and when seen is a clear notice that some math is considerably >> incorrect leading to other such miscalculations to be performed. >> Things like >> the above already have checks in place that ensure no boundries are being >> crossed/overflowed or underrun but it surely makes processing results >> building >> future products a bitch. One instance is the calculation of threads >> for example >> firefox can be seen using upto or more 338% of the CPU. Thats >> impossible its >> like saying anyones CPU grew by 400%. > > I could understand a bit of overflow as stats are snapshots which may not > be instuntanious, but 31GB instead of under 8GB is hardly a rounding > issue / > overflow. > > With respect to top showing greater than 100% by how much are you talking? > Do your realise that each core = 100%? So if you have a quad core your > system > total will be 400% not 100%? > That's his point, you cannot use 400% of a system as a whole, his point is that top should report 100% where each core accounts for 25% ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/16/12 11:28 PM, John Kozubik wrote: > > Friends, > > I was disappointed to see that 8.3-RELEASE is now slated to come out in > March of 2012. This will be ~13 months since 8.2-RELEASE and is typical > of a trend towards longer gaps between minor releases. > > I also see that undercutting the current release before wide deployment > and maturity is continuing. 7.0 came (barely) after 6.3, which was bad > enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2. > > Finally, the culture of "that's fixed in CURRENT" or "we built those > changes into (insert next major release)" continues to get worse. It's > difficult to escape the notion that FreeBSD is becoming an operating > system by, and for, FreeBSD developers. > Wholeheartedly agree. I'm having an increasingly difficult time defending FreeBSD in our company against the advances of debian kfree which is much easier to maintain. Can we get back to the 4.x release style and, hopefully, see some 9.7, 9.8... ? Check this PR I opened some months ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=161123&cat=kern It was planned for 9.0-RELEASE, there is no mention of 8.x That's just the kind of problem John raises here. I can't keep on defending FreeBSD when the minor fix to a major bug isn't backported, and only makes it to the next major version, 4 or 5 months from now. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/17/12 4:39 PM, Mark Felder wrote: > Why is everyone so afraid of running -STABLE? Plenty of stuff gets > MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's > frustrating to us that VMWare only supports -RELEASE and it took until > ESX 5 to officially support 8.2! > > More releases / snapshots of -STABLE helps people on physical servers, > but anyone who runs VMs on Xen or VMWare won't get any support for those > versions because they didn't go through the QA process yet. FreeBSD is > increasingly becoming a third world citizen thanks to virtualization > efforts being focused on Linux, so I feel that more frequent releases > won't help as many people as you think. > Running FBSD in a *production* environment means you want something stable and tested. -STABLE does not fulfill the requirements I'm afraid. We've had to downgrade some boxes from 8.2-STABLE to -RELEASE here. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/20/12 2:38 PM, Gleb Smirnoff wrote: > Damien, > > On Tue, Jan 17, 2012 at 10:09:55AM +0100, Damien Fleuriot wrote: > D> I'm having an increasingly difficult time defending FreeBSD in our > D> company against the advances of debian kfree which is much easier to > D> maintain. > D> Can we get back to the 4.x release style and, hopefully, see some 9.7, > D> 9.8... ? > D> > D> Check this PR I opened some months ago: > D> http://www.freebsd.org/cgi/query-pr.cgi?pr=161123&cat=kern > D> > D> It was planned for 9.0-RELEASE, there is no mention of 8.x > D> That's just the kind of problem John raises here. > D> > D> I can't keep on defending FreeBSD when the minor fix to a major bug > D> isn't backported, and only makes it to the next major version, 4 or 5 > D> months from now. > > Hey, what's the problem here? Fix for kern/161123 has been committed to > stable/8! > > You reminded me, and I promptly did merge, w/o any argument, albeit I have > no ability to test it properly on stable/8. I trust you, that you have tested > in on stable/8, but if anything breaks, guess who would be blamed: me or you? > Don't be mistaken, I greatly appreciate the work you put into this and the time you devoted to fixing this issue which was *a real annoyance* in our case. I'm not saying you didn't merge it Gleb, I'm saying for a lng time I had to manually patch the 8.2-RELEASE boxes, because for some reason that I don't know/understand, the patch couldn't (and still hasn't been, I guess) be merged with 8.2-RELEASE. Actually, on topic, what prevents patches from being merged with -RELEASE, as opposed to waiting for a new -RELEASE bump ? Regarding the patch, we've been running it since I submitted it on over 20 firewalls and they're all humming happily. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 1/20/12 2:59 PM, Gleb Smirnoff wrote: > On Fri, Jan 20, 2012 at 02:43:55PM +0100, Damien Fleuriot wrote: > D> Don't be mistaken, I greatly appreciate the work you put into this and > D> the time you devoted to fixing this issue which was *a real annoyance* > D> in our case. > D> > D> I'm not saying you didn't merge it Gleb, I'm saying for a lng > D> time I had to manually patch the 8.2-RELEASE boxes, because for some > D> reason that I don't know/understand, the patch couldn't (and still > D> hasn't been, I guess) be merged with 8.2-RELEASE. > D> > D> Actually, on topic, what prevents patches from being merged with > D> -RELEASE, as opposed to waiting for a new -RELEASE bump ? > > It cannot be merged into RELEASE! RELEASE is a point on a branch, > as soon as RELEASE had been released, you can't push anything into > it, unless you have a time machine. > > So, the fix has been merged to the branch you reported problem on, > this means that it'll be available in the next release from this > branch - in 8.3-RELEASE. > Ok good to know (and too bad for us running -RELEASE). I guess at some point I'll have to study the possibility of us running -STABLE, perhaps that would be acceptable. Thanks for ensuring it'll be in 8.3 anyway :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: mdconfig(8) argument parsing.
On 1/25/12 11:44 AM, Edward Tomasz Napierała wrote: > Patch below changes the way mdconfig(8) parses its arguments: > it removes the ordering requirement and makes error messages > more descriptive; it also makes the code more readable by > getting rid of the 'cmdline' variable. > > Now, the mdconfig(8) syntax is somewhat weird, and I'm not sure > I tested all the ways people use it. Thus, testing is welcome. > > http://people.freebsd.org/~trasz/mdconfig-parsing.diff > Against what version is this patched ? We're running 8.2-RELEASE here at work, I've got private boxes with 8.2-STABLE, and 2 test ones with 9.0-RELEASE. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: PostgreSQL benchmarks (now with Linux numbers)
On 2/23/12 2:22 PM, John Baldwin wrote: > On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: >> On 02/22/2012 01:42, Ivan Voras wrote: >>> The Dragonfly team has recently liberated their VM from the giant lock and >>> there are some interesting benchmarks comparing it to FreeBSD 9 and a > derivative of RedHat Enterprise Linux: >>> >>> http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg8.html >>> >>> Other developments are described in their release notes: >>> http://www.dragonflybsd.org/release30/ >> >> The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty >> notable, what prevents us from enabling that by default? > > It makes all your SYSV SHMs wired. That's fine if you are running a dedicated > server using SYSV SHMs where you want that process to use all the RAM in the > machine (e.g. a pgqsl server). It's not so great for a general purpose load > where you would like an otherwise-idle process using SYSV SHMs to have the > SHMs > paged out to swap if other processes on the machine need memory and the box is > under memory pressure. > John, any chance we can get that in layman's terms ? I'm totally no coder, but I'd really like if we could do this at my work place to increase our firewalls' performances. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Blackhole routes vs firewall drop rules
On 26 Feb 2012, at 14:34, Bob Bishop wrote: > Hi, > > I'd like to hear from somebody who understands this stuff on the relative > merits of blackhole routes vs firewall drop rules for dealing with packets > from unwanted sources. I'm particularly interested in efficiency and > scalability. Thanks > First, there is no definitive answer to your question because they both address different issues. With a null (or blackhole) route, you effectively suppress ALL the traffic from an unwanted destination. Note however that, unless you perform reverse path checks on your routers (google urpf and DFZ), ALL the packets from the source IP will still reach your servers and be processed, in the case of protocols without sessions (UDP comes to mind, ICMP as well). This means your server might still work for no reason while processing the packets which will be dropped later. Firewalling OTOH doesn't exhibit this drawback. It also has the huge advantage of being able to filter on more aspects than simply the source IP: protocol, ports, rate limiting, automatic blacklisting... to name but a few of PF's capabilities. You may want to be more accurate about your *needs* before asking us to discuss the *means* to attain them, though. Hope that helps.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd 9.0 can't detect ethernet card
Hello Elman, None of us was born a seer so you might want to tell the model of the network card. On 3/5/12 12:16 PM, Elman wrote: > Hallo hacker. > > I try install freebsd 9.0 in server Hp proliant ML370 G6, in process install, > freebsd can't detect ethernet card in automatic. Freebsd doesn't support the > ethernet card driver in HP ML370 G6? > > Thanks > Regards. > Elman > Powered by Telkomsel BlackBerry® > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: mfid, raid monitoring daemon
On 3/8/12 7:08 PM, Sean Bruno wrote:
> I'm trying to decide if I should cram "mfid" for mfi(4) controllers into
> the src tree or if we should package it up into a ports package. I
> suspect that either one is acceptible, but it seems to make more sense
> to put it into the src tree since mfiutil is also there.
>
> Comments?
>
> Sean
>
> ref: http://svnweb.freebsd.org/base/user/sbruno/mfid/
For what it's worth, we use the following plugin for our Nagios RAID
checks on MFI controllers.
I'm attaching the nagios script below for those that are interested.
The downside is it uses Megacli and all the linux compatibility stuff :(
I for one would be *delighted* if a system came up that would allow me
to skip the whole linux compatibility layer !
IMO:
- port: flexibility (can choose to install or not, can update whenever
you want)
- base: no hassle with managing the port, at the cost of less
flexibility (installed by default, updates only with the base system)
I slightly favor a port.
=== Nagios script begins ===
#!/usr/bin/perl -w
# check_megaraid_sas Nagios plugin
# Copyright (C) 2007 Jonathan Delgado, delg...@molbio.mgh.harvard.edu
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
#
#
# Nagios plugin to monitor the status of volumes attached to a LSI
Megaraid SAS
# controller, such as the Dell PERC5/i and PERC5/e. If you have any
hotspares
# attached to the controller, you can specify the number you should
expect to
# find with the '-s' flag.
#
# The paths for the Nagios plugins lib and MegaCli may need to me changed.
#
# Code for correct RAID level reporting contributed by Frode Nordahl,
2009/01/12.
#
# $Author: delgado $
# $Revision: #8 $ $Date: 2009/03/06 $
use strict;
use Getopt::Std;
use lib "/usr/lib/nagios/plugins";
use utils qw(%ERRORS);
our($opt_h, $opt_s, $opt_o, $opt_m, $opt_p);
getopts('hs:o:p:m:');
if ( $opt_h ) {
print "Usage: $0 [-s number] [-m number] [-o number]\n";
print " -s is how many hotspares are attached to the
controller\n";
print " -m is the number of media errors to ignore\n";
print " -p is the predictive error count to ignore\n";
print " -o is the number of other disk errors to ignore\n";
exit;
}
my $megacli = 'sudo /usr/local/sbin/megacli';
my ($adapters);
my $hotspares = 0;
my $hotsparecount = 0;
my $pdbad = 0;
my $pdcount = 0;
my $mediaerrors = 0;
my $mediaallow = 0;
my $prederrors = 0;
my $predallow = 0;
my $othererrors = 0;
my $otherallow = 0;
my $result = '';
my $status = 'OK';
sub max_state ($$) {
my ($current, $compare) = @_;
if (($compare eq 'CRITICAL') || ($current eq 'CRITICAL')) {
return 'CRITICAL';
} elsif ($compare eq 'OK') {
return $current;
} elsif ($compare eq 'WARNING') {
return 'WARNING';
} elsif (($compare eq 'UNKNOWN') && ($current eq 'OK')) {
return 'UNKNOWN';
} else {
return $current;
}
}
if ( $opt_s ) {
$hotspares = $opt_s;
}
if ( $opt_m ) {
$mediaallow = $opt_m;
}
if ( $opt_p ) {
$predallow = $opt_p;
}
if ( $opt_o ) {
$otherallow = $opt_o;
}
# Get the number of RAID controllers we have
open (ADPCOUNT, "$megacli -adpCount |")
|| die "error: Could not execute MegaCli -adpCount";
while () {
if ( m/Controller Count:\s*(\d+)/ ) {
$adapters = $1;
last;
}
}
close ADPCOUNT;
ADAPTER: for ( my $adp = 0; $adp < $adapters; $adp++ ) {
# Get the number of logical drives on this adapter
open (LDGETNUM, "$megacli -LdGetNum -a$adp |")
|| die "error: Could not execute $megacli -LdGetNum -a$adp";
my ($ldnum);
while () {
if ( m/Number of Virtual drives configured on adapter
\d:\s*(\d+)/i ) {
$ldnum = $1;
last;
}
}
close LDGETNUM;
LDISK: for ( my $ld = 0; $ld < $ldnum; $ld++ ) {
# Get info on this particular logical drive
open (LDINFO, "$megacli -LdInfo -L$ld -a$adp |")
|| die "error: Could not execute $megacli -LdInfo -L$ld
-a$adp";
m
Re: mfid, raid monitoring daemon
On 3/9/12 5:53 PM, Vincent Hoffman wrote: > On 09/03/2012 11:52, Damien Fleuriot wrote: >> On 3/8/12 7:08 PM, Sean Bruno wrote: >>> I'm trying to decide if I should cram "mfid" for mfi(4) controllers into >>> the src tree or if we should package it up into a ports package. I >>> suspect that either one is acceptible, but it seems to make more sense >>> to put it into the src tree since mfiutil is also there. >>> >>> Comments? >>> >>> Sean >>> >>> ref: http://svnweb.freebsd.org/base/user/sbruno/mfid/ >> >> For what it's worth, we use the following plugin for our Nagios RAID >> checks on MFI controllers. >> I'm attaching the nagios script below for those that are interested. >> The downside is it uses Megacli and all the linux compatibility stuff :( >> >> >> >> I for one would be *delighted* if a system came up that would allow me >> to skip the whole linux compatibility layer ! >> > Can you not get enough info via mfiutil? not to mention there is a > FreeBSD megacli > sysutils/megacli as well as sysutils/linux-megacli > > that said I favour a port for the reasons you give below. > > Vince We've never tried with mfiutil actually, could be worth a look. Regarding megacli, we're using the linux one and I'd be so happy to get shot of it, too many dependencies... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Upcoming release schedule - 8.4 ?
On 13 Jun 2012, at 19:27, John Baldwin wrote: > On Wednesday, June 13, 2012 11:52:28 am Adrian Chadd wrote: >> On 13 June 2012 05:53, John Baldwin wrote: >> You don't need to change the FreeBSD culture. We'd love to do an 8.4 release. And an 8.5 release, and 8.6 release, etc. The problem is one of resources and time, not of culture/desire. >>> >>> I disagree. The pace of X.0 releases is a deliberate choice FreeBSD >>> has made and directly impacts the number of "live" branches in existence. >>> Given our developer base, we can't really support 3 branches concurrently >>> (head + 2 stable like we have now with head, 9, and 8). Having longer lived >>> stable branches requires either increasing resources to support exising >>> releases longer, or slowing the pace of X.0 releases (but more aggressively >>> merging things from HEAD back). The latter case, especially, is part of >>> the culture and would be a choice we as a Project would have to make. >> >> Right, but I don't think the freebsd project would really mind or >> change much if more people came on board to handle legacy releases and >> support them. >> >> If you're a company that uses FreeBSD stable releases, please consider >> contributing engineering resources and/or donations to the Foundation >> to improve the support of said stable releases. :) > > No, that doesn't actually work. Having additional support on a stable > branch requires someone able to 1) commit changes to stable branches and > 2) be able to cut newer releases from said branches (i.e. doing the work > of re@). You cannot get that as an outside entity. It requires buy-in > from the Project itself. > Jumping in. I for one, as a fbsd admin on corporate servers ( read not commiter), would dearly like less releases but a more aggressive MFC approach. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Upcoming release schedule - 8.4 ?
On 6/14/12 9:09 AM, Chris Rees wrote: > On Jun 14, 2012 5:52 AM, "Wojciech Puchar" > wrote: >>> >>> Friends, >>> >>> I am looking at the upcoming release schedule, and I only see 9.1 listed > - can anyone confirm or deny 8.4 ? >> >> >> does it matter. cvsup RELENG_8 and you see updates are done constantly. >> just sometime somebody decide to change number :) > > Except STABLE is no good for production, and the problem is EoL- updates > and support stop. > > Chris Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). I've moved us to 8.3-STABLE recently and am quite happy with it, so far. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Upcoming release schedule - 8.4 ?
On 14 Jun 2012, at 15:13, Mark Felder wrote: > On Wed, 13 Jun 2012 16:49:18 -0500, Damien Fleuriot wrote: > >> >> I for one, as a fbsd admin on corporate servers ( read not commiter), would >> dearly like less releases but a more aggressive MFC approach. > > Less releases such as less frequent MAJOR releases (7.0, 8.0, 9.0...) or less > MINOR releases as well? (8.4, 8.5, 9.1...) Less major, I don't mind minor ones as much to be honest. I welcomed 8.3 with open arms, I'm steering clear of 9.x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Upcoming release schedule - 8.4 ?
On 14 Jun 2012, at 16:41, Mark Linimon wrote: > On Thu, Jun 14, 2012 at 10:29:22AM +0200, Damien Fleuriot wrote: >> Whoever said STABLE is no good for production ? >> >> I used to make us stick to 8.2-RELEASE here at work, but some bugfixes >> are just too important to skip (we're running firewalls and had a >> problem with a CARP bug). > > In theory we try our best to keep -STABLE, well, stable in behavior and > not just the API, but in practice any given snapshot of -stable may or > may not have uncaught regressions in it. > > I reiterate, the major difference between -stable and -release is a more > thorough QA process for the latter :-) > > mcl We're indeed pretty happy with 8-STABLE :) We're ready to take the risk of a regression if the update squashes a bug that's a major PITA Thanks for your work on the project guys___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Upcoming release schedule - 8.4 ?
On 6/15/12 4:25 AM, Adrian Chadd wrote: > Hi, > > 9 will mature as people use it and report bugs/regressions. It would > be really great if you could try some of your workload on -9 and > provide feedback and file PRs. > > Engaging with the community (and hiring developers :) is by far the > best way to get things to mature quickly. > > 2c, > > Adrian I wholeheartedly agree, however the cheer number of problem reports I've seen on the ml when 9.0 came out really chilled me away. There are not many boxes I could try 9.0 on, because they're in production with pfsync to conserve client sessions and I'm loath to take risks with most of our firewalls. I'm thinking we might jump straight from 8.x to 10 when the time comes, I'm really looking forward to Gleb's work on CARP and PF ;) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Upcoming release schedule - 8.4 ?
On 6/15/12 10:52 AM, Mark Linimon wrote: > On Fri, Jun 15, 2012 at 10:16:30AM +0200, Damien Fleuriot wrote: >> I'm thinking we might jump straight from 8.x to 10 when the time comes, >> I'm really looking forward to Gleb's work on CARP and PF ;) > > I don't know why you might think one .0 release would be more mature > than another .0 release. Maybe I'm misunderstanding. > 10.0 hasn't scared the hell out of me, yet, on the ml... :p >> There are not many boxes I could try 9.0 on, because they're in >> production with pfsync to conserve client sessions and I'm loath to >> take risks with most of our firewalls. > > This is where having one or more systems for development is key. > My problem here is that the dev and preprod platforms are actively used by our devs, which means that it costs us money if we have an outage. I suppose I could try upgrading the backup box to 9.0 then swapping over to it. My main problem here is that we've got many machines to administer, on top of the network and security, and there's just me and myself that touch the firewalls. It always comes down to time being short... > Installations like yours are in a far better situation to test FreeBSD under > realistic loads than are all but a few of the FreeBSD developers. I would > urge testing long before the leadup to a .0 release, not afterwards. > I guess it couldn't hurt overmuch for me to test 9.0 on one of our projects, I could update 1 of the 4 boxes to 9.0 and make it carp master. If that goes well, 1-2 weeks later I could push 9.0 on another project which uses 4 *active* firewalls. This is a medium packet-rate [2][3] real life [1] project and could yield interesting results for you guys. @gleb Are there any counter indications against running 8-STABLE and 9-STABLE sets of firewalls with CARP and pfsync ? [1] Firewalls share 8 CARP IPs and are each master on 2 at a given time. Firewalls use VLAN tagging over a link aggregation interface. Firewalls use relayd to dynamically rdr packets to backend servers. [2] IRQs on broadcom NIC: # vmstat -i interrupt total rate irq9: acpi0 22 0 irq20: uhci3 20 0 irq21: uhci2 uhci4+ 25 0 cpu0: timer 2089687121 2000 irq256: bce033684311 32 irq257: bce1 8636578820 8266 [3] PF output: Status: Enabled for 12 days 02:10:48 Debug: Urgent Interface Stats for vlan20IPv4 IPv6 Bytes In5225964204350 Bytes Out 55365130031720 Packets In Passed 48930005750 Blocked 1449678030 Packets Out Passed 60052575430 Blocked 4783780 State Table Total Rate current entries16556 searches 2264698647621679.1/s inserts 1368370473 1309.9/s removals 1368353917 1309.9/s Counters match 1650605688 1580.1/s ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
On 7/3/12 3:36 PM, Mark Felder wrote: > On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav wrote: > >> >> I don't think there will be as much whinging as you expect. Times have >> changed. > > Agreed; if we need DNS in base (really, why?) Because when people install a server, they expect it to be able to resolve host names ? I fail to see how I'd be able to build BIND (or whatever other resolver) from the ports tree if my server wasn't able to download the sources in the first place. Using a third-party's name servers is not an option ;) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Pull in upstream before 9.1 code freeze?
On 7/5/12 11:03 AM, Doug Barton wrote:
> On 07/05/2012 01:28, Peter Jeremy wrote:
>> On 2012-Jul-05 09:22:25 +0200, Jonathan McKeown
>> wrote:
>>> As for the idea that Linux refugees need extra help to migrate,
>>> that's the sort of thinking that led to things like:
>>>
>>> alias dir=ls
>>
>> Whilst we're on the subject, can we please also have #define BEGIN
>> { #define END } wired into gcc to help people migrating from Algol
>> and Pascal.
>
> Um, this kind of elitist crap really isn't helpful.
>
> If the new feature gets created, and you don't want to use it, turn it
> off. No problem.
>
> I appreciate the people who've spoken up as to why they wouldn't want
> to use it, but I haven't seen anything yet that says "having this
> feature is a universally bad idea."
>
> Doug
>
As long as it can be toggled off system-wide, persistently (sysctl?), I
can't see the harm in bringing that in.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On 7/5/12 12:15 PM, Jonathan McKeown wrote:
> On Thursday 05 July 2012 11:03:32 Doug Barton wrote:
>> On 07/05/2012 01:28, Peter Jeremy wrote:
>>> On 2012-Jul-05 09:22:25 +0200, Jonathan McKeown
>>>
>>> wrote:
As for the idea that Linux refugees need extra help to migrate,
that's the sort of thinking that led to things like:
alias dir=ls
>>>
>>> Whilst we're on the subject, can we please also have #define BEGIN
>>> { #define END } wired into gcc to help people migrating from Algol
>>> and Pascal.
>>
>> Um, this kind of elitist crap really isn't helpful.
>
> It was intended to be a slightly humorous response to your original question:
>
>> why would you *not* want a feature that tells you what to
>> install if you type a command that doesn't exist on the system?
>
> rather than ``elitist crap'' (as was the deliberately the over-the-top
> comparison to Clippy). I don't think suggesting that someone who wants to use
> a system learn how it works is elitist; and I don't object to optional tools
> to help them ``settle in'' (but see below).
>
> You might also notice that I made a suggestion that might help people
> migrating - namely some adaptation of the Unix Rosetta Stone in the Handbook
> so that people who know how to do something in Linux are quickly guided to
> the best way to do it in FreeBSD (and perhaps vice versa).
>
>> If the new feature gets created, and you don't want to use it, turn it
>> off. No problem.
>
> No. I think this is entirely the wrong way round. If the new feature is
> created and you want it, turn it on. Don't make me turn off something I
> didn't want in the first place. Given the choice between a system in which I
> switch on whatever I need, versus one which has absolutely everything
> switched on where I spend ages switching it all off/deinstalling it all, I
> know which I prefer - and others have made similar comments.
>
I have to disagree here.
This feature is also intended to make things easier for new and/or
inexperienced users.
Having to enable it manually defeats its very purpose.
I for one wouldn't mind it being enabled by default as long as I can
disable it via a sysctl or rc.conf variable.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On 7/5/12 6:38 PM, Wojciech Puchar wrote: >> inexperienced users. >> >> Having to enable it manually defeats its very purpose. > > so is FreeBSD future direction to be moron-OS just like linux is now, or > is that just another stupid idea on that forum that came and... will pass? > > Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. The "-p" flag to netstat comes from linux and I would dearly like to see it on BSD, for example. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On 7/5/12 7:18 PM, Warner Losh wrote: > > On Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: > >> >> On 7/5/12 6:38 PM, Wojciech Puchar wrote: >>>> inexperienced users. >>>> >>>> Having to enable it manually defeats its very purpose. >>> >>> so is FreeBSD future direction to be moron-OS just like linux is now, or >>> is that just another stupid idea on that forum that came and... will pass? >>> >>> Quite important. There are still people that want normal OS. >> >> >> Just because you don't like the idea doesn't make it stupid, and just >> because it comes from linux doesn't make it bad. > > Both true. However, if the database lookups took a long time, or had a high > overhead to maintain, then it would be stupid to have on by default. > > Warner > As a matter of fact, I for one dislike the idea of a feature that suggests packages to install. I hate it on linux, and I would hate it here as well. I would definitely be turning it off (or keeping it disabled, whichever), however I can see why some people would want such a feature and use it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Replacing BIND with unbound (Was: Re: Pull in upstream before 9.1 code freeze?)
On 7/9/12 12:44 AM, Dan Lukes wrote: > On 07/08/12 23:55, Doug Barton: >> On 07/08/2012 07:41, Dan Lukes wrote: > ... >> Sorry, you're not understanding what is being proposed. Specifically >> you're confusing the system stub resolver (the bit that's compiled into >> libc, and used by binaries) and the resolving name server (BIND). No one >> is proposing to replace the stub. > > > libc stub resolver is BIND code based, so I assumed that arguments > against BIND apply to it as well. > > I'm happy it's not true. > > In my humble opinion, no resolving name server need to be part of base > at all. We have no DHCP, VPN, RADIUS, WWW, ... server in the base as well. > > > Thank you for clarifying. > > Dan > Whereas you don't need a DHCP, VPN, RADIUS or WWW server to do *anything at all* with your newly installed BSD machine, you sort of need a DNS resolver... I for one am not going to use a 3rd party resolver, even if only to download the ports' source code for BIND, so I'm happy it's provided in the base. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel: abra-kadabra
On 10 Jul 2012, at 12:10, Wojciech Puchar wrote: > this is what i've got from kernel (same visible after dmesg of course) > > > Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 ((hh6ttt6p2d4 > )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die txoiedtn eo dn > sosini ggnsnaalilg n1a1l > Jul 9 08:56:53 .. kernel: 1 > Jul 9 08:56:53 ... kernel: > Jul 9 08:56:53 ... kernel: <<66>>11 > Jul 9 08:56:53 ... kernel: 1 > Jul 9 08:56:53 ... kernel: > > everything before and after seems usual. > > when reading every second letter it SEEMS to make more sense but still not > much. > > What it is? > You're seeing several messages at jumbled together, or your message and other parts of the buffer. Either way, you can see the word "signal" there ;)___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel: abra-kadabra
On 7/10/12 4:36 PM, Wojciech Puchar wrote: > > > On Tue, 10 Jul 2012, Damien Fleuriot wrote: > >> >> On 10 Jul 2012, at 12:10, Wojciech Puchar >> wrote: >> >>> this is what i've got from kernel (same visible after dmesg of course) >>> >>> >>> Jul 9 08:56:53 ... kernel: <<66<>p>ipd6id >p336i65d0 43432 >>> ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex >>> die txoiedtn eo dn sosini ggnsnaalilg n1a1l >>> Jul 9 08:56:53 .. kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> Jul 9 08:56:53 ... kernel: <<66>>11 >>> Jul 9 08:56:53 ... kernel: 1 >>> Jul 9 08:56:53 ... kernel: >>> >>> everything before and after seems usual. >>> >>> when reading every second letter it SEEMS to make more sense but >>> still not much. >>> >>> What it is? >>> >> >> You're seeing several messages at jumbled together, or your message >> and other parts of the buffer. >> >> Either way, you can see the word "signal" there ;) >> > i think it was httpd (probably PHP trash) crashed with sig11 but want to > be sure. > > httpd rarely do crash... Strange i have ports rather up to date and no > KNOWN vulnerabilities are according to portaudit output. > > how can i prevent mixing kernel messages? > > i have > > options PRINTF_BUFR_SIZE=256# Prevent printf output being > interspersed. > > in kernel config Regarding the mixing of kernel messages I'm afraid I won't be able to help with that. Regarding your HTTPd dying, I've also experienced signal 11 quits when I was using apache and PHP as a module. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel module parallel build?
On 5 Dec 2012, at 18:39, Warner Losh wrote: > > On Dec 5, 2012, at 9:42 AM, John Baldwin wrote: > >> On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote: >>> On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin wrote: >>> Hmm, I certainly see the module directories being built in parallel. Some of the make jobs may not be as obvious since links are silent (no output unless there is an error). >>> This is definitely not the behaviour that I see trying to build any version >>> of FreeBSD. I see the same behaviour as Andre: the depend and all targets >>> both iterate through the module directories sequentially. It never builds >>> two module subdirectories concurrently. >> >> Hmm, I think I was confused by seeing kernel builds intermingle with the >> associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I see >> similar things in world builds where I will see parallel builds of bin vs >> sbin >> vs usr.bin vs usr.sbin, but within each of those directories the builds go >> sequentially. I think you would need to change bsd.subdir.mk if you want to >> fix this. > > The builds are in parallel, just that the parallelism is low because it is > only parallel within the module being built. Would love to see a fix. > > Warner > All trolling aside, I believe an awesome fix to be setting module override in /etc/make.conf to only build the 4-5 specific modules one needs. To be honest I think this configuration tweak should be advertised a bit more as it definitely speeds up kernel builds. I would be happy to check if this is advertised in the handbook in the "rebuilding kernel" section and enhance its visibility if required. I can provide en_US and fr_FR. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: disadvantages of running 8.3 kernel on freebsd 8.2 system
On 17 Jan 2013, at 20:27, Devin Teske wrote: > > On Jan 17, 2013, at 11:14 AM, Steven Hartland wrote: > >> - Original Message - From: "Devin Teske" >>> You're the perfect person to help us figure out why when we: >>> >>> 1. back-port mfi(4) from stable/8 into releng/8.3 (8.3-RELEASE-p5 at the >>> time of back-port) >>> >>> 2. Succeed in getting 8.3 to boot on Thunderbolt card >>> >>> 3. mfiutil produces Inappropriate ioctl for device >>> >>> Even after… >>> >>> 4. Recompiling mfiutil from stable/8 (albeit in a releng/8.3 build >>> environment -- back ported headers applied for new macros even) >>> >>> Any hints on where to go next to restore mfiutil access? >> >> You also need to backport mfiutil too. >> >> I have a patch set for 8.3 which include latest mfi driver, mfiutil and >> a large set of mfi driver fixes, even head has some rather serious issues >> although mainly around error handling on tbolt cards. >> >> We're running this in production so believe its a good stable set. >> >> If you would like the patch set just let me know. >> > > I can't resist when you combine words like "production" and "8.3" (smiles) > ? Are you saying 8.3 isn't production worthy ? Works like a charm here for us. 50+ boxes running 8.x, most of which are 8-stable. No offence meant, but I'd take 8.3 over 9.x any day. Any night too, for that matter. YMMV but PF + pfsync + carp (and some boxes with nginx or relayd on top) is pretty good for our workload on 8.3. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: removing plip from GENERIC
On 30 Jan 2013, at 22:46, Eitan Adler wrote: > On 30 January 2013 16:39, Eitan Adler wrote: >> There has been some discussion about removing plip support from GENERIC >> kernels. >> plip still appears in sys/conf/NOTES > > A quick follow up to this: the documentation about plip from the > handbook has already been removed by others. > > > -- > Eitan Adler > I speak only for myself but no objection here, I remove it (as well as // port) from every single kernel build. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Chicken and egg, encrypted root FS on remote server
On 20 Feb 2013, at 08:46, Paul Schenkeveld wrote: > On Wed, Feb 20, 2013 at 02:42:57AM -0500, Jason Hellenthal wrote: >> Just a thought with no working example but… >> >> bootp / tftp - from a remote secured management frame to TX a key filesytem >> to unlock your rootfs. >> >> Could be something as simple as a remote wireless adhoc server with a 64GB >> thumbdrive to hold your data or just enough to tell the system where to get >> it. >> >> Considering a key can be any length string of a sort just to say but... >> Serve the rootfs key directly from a TXT out of a secured DNS zone only >> visible to so said machines. > > Thank you but manual entry of the passprase is a prerequisite here so > serving the key automatically is not an option. > > With kind regards, > > Paul Schenkeveld > What about getting a remote console like HP's ILO or Dell's DRAC ? You get to login remotely, you can use some degree of access control... you can even remote boot. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ***HELP***
I'VE DONE IT FOR YOU BRO, THE PASSWORD IS "4hLoLum4dBr0", MAKE SURE TO ENTER IT ALL IN CAPS LOCK EVEN THE NUMBERS OR IT WON'T WORK. IF THAT WORKED FOR YOU MAKE SURE TO SEND MONEY VIA PAYPAL TO ohg4wd...@freebsd.org. AGAIN MAKE SURE YOU TYPE IT ALL IN CAPS LOCK BRO OR IT WON'T WORK !!!1! I NEED TO GET BACK TO MY BROS SEE YOU BRO On 16 Jul 2013, at 01:30, West Side Family wrote: > I Need help from all of you guys for this site www.zoo.g ( Admin.zoo.gr ) > to broke up the password!!! THANKS > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
