Re: Intel c602 chipset support?
On Thu, 19 Apr 2012, G??t Andr??s wrote: > Hi, > > Could you try FreeBSD it on a machine with a chipset like this? 8.3-RELEASE is the first version (outside of -CURRENT) to support the Intel c60X chips. So, yes, FreeBSD does support the chipset now. Works great, I only had a small problem with sysinstall needing to re-scan devices to see the drives (but that's a sysinstall bug, see the other thread for details). Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: FreeBSD 8.3-R sysinstall does not "see" disks that are recognized during boot
On Wed, 18 Apr 2012, Harris, James R wrote: > > Andy and I worked this out offline - workaround was to go to > Options|Re-scan which caused the devices to show up in the sysinstall > menu. I'm adding details here for future reference. > > 1) C60x chipsets have the 6 traditional SATA ports, plus 4 or 8 SAS > ports. Only the latter are controlled by the isci(4) driver. > 2) The IDE/AHCI/RAID modes apply only to the traditional SATA ports. > 3) In Andy's case, going to Options|Re-scan Devices caused the disks to > show up. This problem seems to be system or platform-dependent, as I > was not able to reproduce with 8.3 memstick image on my C600 systems. > 4) There was a problem with initial device scan using isci(4) on > 7-STABLE, which necessitated r233371. This was MFC'd back to 8-STABLE, > but after 8.3 was released. I'm fairly convinced this is the root cause > of Andy's problem, but don't have any easy way to verify. First, I want to thank James and the other responders for help getting me squared away. Something that may be of specific use for others (James has covered the most relevant points...at blazing speed, what an asset to the community), is that the isci support in 8.3-R will now enable FreeBSD compatibility with most of the new Supermicro server platforms. And a new lesson was learnedfirst thing to try when sysinstall fails to recognize hardware is to re-scan devices. Never needed that across thousands of installs (dating to 2.2.8), and didn't even know it existed. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 8.3-R sysinstall does not "see" disks that are recognized during boot
I've got a new supermicro server I'm trying to get FreeBSD on. It uses the Intel c602 chipset, and it's my understanding that support for that chipset (c60X) was recently added via the isci driver. Ok, great, that explains why 8.2-R and 9.0-R didn't see the drives. So, I grabbed the memstick image of 8.3-RELEASE that is on the ftp server, booted it up, and sure enough, as the dmesg scrolls I see it now properly recognizes da0 and da1, as it should (the memstick is da2). It sees the disks fine at this point, everything looks good. However, once the system finishes booting and loads into sysinstall, and I go to partition the drives, I get "No disks found! Please verify that your disk controller is being properly loaded at boot time". Any suggestions for avenues to troubleshoot this? I have pictures to document if it helps. Seems very odd. I confirmed the behavior with the SATA set to IDE, AHCI, and RAID modes. (The drives were recognized as da0 and da1 during bootup in all three modes, but not by sysinstall.) Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Intel c602 chipset support?
Hi there, Does anybody know if there are plans to support the Intel c602 chipset any time soon? Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why doesn't this startup script execute on boot?
On Wed, 12 May 2010, Chuck Swiger wrote: > Hi-- > > On May 12, 2010, at 4:46 PM, Andy Dills wrote: > > I'm working on getting p0f integrated with amavisd-new. Everything is > > great, with the exception that I can't get the neccessary commands to > > execute on boot. > > The amavid-p0fanalyzer script should have been installed if you used the port: Well, isn't that convenient! I decided after I had installed amavisd to add on the p0f support, I didn't realize there was an option to install that via port...I had just gone in and installed the p0f port by itself. But looking at the options for the amavisd-new, there it is indeed. Thanks for your help. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Why doesn't this startup script execute on boot?
I'm working on getting p0f integrated with amavisd-new. Everything is
great, with the exception that I can't get the neccessary commands to
execute on boot.
I started with rc.local and that didn't work. So I made this simple script
in /usr/local/etc/rc.d/p0f:
---
#!/bin/sh
# PROVIDE: p0f
# REQUIRE: LOGIN
# BEFORE: securelevel
# KEYWORD: shutdown
. "/etc/rc.subr"
name="p0f"
rcvar=`set_rcvar`
command="/usr/local/bin/p0f"
command_args="-l 'tcp dst port 25' 2>&1 | /usr/local/bin/p0f-analyzer.pl 2345 &"
pidfile="/var/run/$name.pid"
# read configuration and set defaults
load_rc_config "$name"
: ${p0f_enable="NO"}
run_rc_command "$1"
---
It does not execute on boot (yes, it's executable). It executes just fine
by hand.
I'm assuming it has something to do with redirecting stdout and stderr to
another script which is then shoved into the background?
How do I work around this?
(BTW, FreeBSD 8.0-STABLE #2: Wed May 12 13:28:18 EDT 2010)
Thanks,
Andy
---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PPP doesn't set the correct interface in 7-STABLE
On Wed, 6 Aug 2008, Mike Tancsa wrote: > At 10:16 AM 8/6/2008, Andy Dills wrote: > > > I'm trying to setup pptpd to enable VPN connections. This worked well in > > all versions of FreeBSD prior to 7. > > I would turf pptpd and look at mpd51 from the ports. It is far, far better > maintained and is quite solid as an LNS as well as PPTP termination server. Yep, it looks like this is definitely the best solution, for a number of reasons. Thanks for the pointer. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PPP doesn't set the correct interface in 7-STABLE
I'm trying to setup pptpd to enable VPN connections. This worked well in all versions of FreeBSD prior to 7. Now, however, the interface in the routing table is incorrectly set to that of the ethernet card, rather than the appropriate tun interface. There is a months-old bug report detailing this: http://www.freebsd.org/cgi/query-pr.cgi?pr=122068&cat= He mentions two workarounds: there are two way to fix it. 1. use differenet subnet for vpn. Don't use the same subnet for vpn routing. user-ppp will set the correct routing table. 2. downgrade to FreeBSD 6.2 #2 isn't really an option, and #1 isn't clear to me. I tried a couple of different configurations and the interface never seems to get set correctly. Suggestions? Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: INET6 required for SCTP in 7.0?
; My ISP doesn't support IPv6 yet though I know that have > IPv6 netbocks for themselves now if not for the customers > at this stage. Oh, they have them for the customers. They just don't want to upgrade their routers. > There is a reasonable chance that this mail will leave here > over IPv6 for some of the recipients. It will almost > certainly travel over IPv6 for at least one hop. s/IPv6/uucp/ ;) Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: INET6 required for SCTP in 7.0?
On Wed, 5 Mar 2008, Pete French wrote: > O.K., have snipped all the above IPv4 stuff, which actually seems quite > reaosnable (though appears to foorget about STF), but this line... > > > In the meantime, I'd like to only enable IPv6 on IPv6 enabled networks. > > ...I fail to see how not wanting to enable it leads to you wanting > to remove it from the kernel entirely ? That is the bit I don't understand > about all of this discussion. Theres probably hundereds of bits in the kernel > you havent enabled and don't use, why specificly do you want an option > to take IPV6 out ? > > I am genuinely piuzzled - why isn't "ipv6_enabled="NO" sufficient ? That's > what I do on IPv4 networks and it works fine for me. That's actually a good point. I've had a hard time shedding my "trim everything I don't use out of the kernel" mentality over the years. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: INET6 required for SCTP in 7.0?
On Wed, 5 Mar 2008, Mark Andrews wrote: > It would be better to remove the option all together. IPv6 > is no longer a protocol under development. There is no > need to make it optional any more. Having it there really > sends the wrong signal. With all due respect, let's face a couple of facts. IPv4 is going to be the primary protocol for several years to come. There are a few critical reasons, and few people like to point out just how naked the emperor is: - Providing IPv6 currently (and for the forseeable future) provides no return on investment (ROI). Service Providers can't make more money with IPv6, businesses do not get any sort of competitive or perceived advantage from deploying IPv6, and end users certainly don't want to deal with it. - To route IPv6 with the same features and packet forwarding rate as with IPv4, nearly every network will be forced to purchase expensive router upgrades with no other real benefit beyond IPv6 connectivity (which again provides no ROI to justify the capex). Nobody is going to do forklift upgrades just for IPv6, but as routers get normally upgraded IPv6 functionality will indeed slowly expand. - IPv6 provides almost no technological upgrades beyond additional address space. DHCP addressed the auto configuration feature, VPNs addressed IPsec. - IPv4 address spaces will eventually transition to a market commodity model, providing a financial incentive that will encourage significant optimization and provide motive for providers to audit their allocations, and for businesses to part with IP space that they no longer properly utilize. The cost of acquiring IPv4 space will be less than the cost of upgrading to IPv6. Therefore, given a lack of ROI or sufficient technological motivation, and given the significant potential for optimization of existing IPv4 space both via technology and financial incentive, I see a minimum of five years before IPv6 is common. In the meantime, I'd like to only enable IPv6 on IPv6 enabled networks. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's new on the 127.0.0/24 block in 7?
Just to provide a little information in case there is still confusion... On Tue, 4 Mar 2008, Chris H. wrote: > Quoting Greg Black <[EMAIL PROTECTED]>: > > > On 2008-03-04, Chris H. wrote: > > > > > Yes, adding an entry in /etc/rc.conf that provides 254 IP's now > > > reveals: > > > lo0: flags=8049 metric 0 mtu 16384 > > >inet6 ::1 prefixlen 128inet6 fe80::1%lo0 prefixlen 64 > > > scopeid 0x3inet 127.0.0.1 netmask 0xff00 > > > > > > as opposed to: 0x. > > > > If you think the above shows evidence of providing 254 IP addresses, > > it's really time either to catch up on some sleep or learn how these > > things work. > > Quite so. That was my point; adding netmask 255.255.255.0 > (0xff00) gave me 254 addresses. While the netmask > 0x provides 1. At the risk of being pedantic, I'm afraid that isn't true. If adding netmask 255.255.255.0 provided 255 addresses, adding the (default in every version of FreeBSD I'm aware of) netmask of 255.0.0.0 would provide 255x255x255 addresses. That said, there is no way to ifconfig multiple addresses with a single address entry. The netmask of an IP bound to an interface determines the scope of the logical network that can be reached through the given interface, not a range of addresses bound to the interface. So, 127.0.0.1 with a mask of 255.255.255.0 means 127.0.0.0-255 would be reachable via lo0, whereas 127.0.0.1 with a mask of 255.0.0.0 means 127.0-255.0-255.0-255 would be reachable via lo0. In neither case would 127.0.0.2 be bound to lo0 implicitly, you would need to explicitly ifconfig them as aliases for them to be bound to lo0. No worries regardless, netmasks are a common source of misunderstanding and confusion. In a routing context, the subnet mask does indeed affect every address within the subnet, however when binding addresses to an interface, the subnet mask merely controls which addresses are reachable locally on layer 2. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's new on the 127.0.0/24 block in 7?
On Mon, 3 Mar 2008, Chris H. wrote: > > Are you sure it's a /24 you are talking about? My 7.0 disks install > > 127.0.0.1/8 here. > > Really? Where did you get the install disc? Mine clearly doesn't. :( > All I am provided is 127.0.0.1 - not 127.0.0.2,3... 127.0.0.1/8 just means 127.0.0.1 with a netmask of 255.0.0.0. It doesn't imply a default behavior of binding to any other address than 127.0.0.1. But I'm still really confused what you're trying to do... See, the idea of returning multiple 127.0.0.X addressess within RBL is to convey different information while using a single zone. In the beginning, the RBLs would just reply with 127.0.0.1 and use different zones to imply different contexts...now you use a single zone with different 127.0.0.X addresses to convey the same information. But...you don't actually do anything with that resolution beyond determine if a given record is listed or not. You don't actually need to configure or use the various 127.0.0.X addresses that might get returned. On the other hand, if you're using multiple rbldnsd instances, one per zone... hile it's a pain you can indeed configured rbldns to serve multiple zones. Or just bind the additional loopback instances BTW, /etc/netstart is a nice shortcut to avoid fatfingering an ifconfig. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's new on the 127.0.0/24 block in 7?
On Mon, 3 Mar 2008, Chris H. wrote: > Greetings, > I'm having some difficulty working with anything past 127.0.0.1. > It seems impossible to use (create) any addresses on the "loopback" > past 127.0.0.1. > More specifically; I installed rbldnsd from ports, and it worked quite > well on a 6.x install. However, attempting the same config/install on > a 7-RC3 install yields the inability to bind/create 127.0.0.2, or > 127.0.0.3 for rbldnsd to answer on - all queries are refused. The > same pinging/digging, etc. > > The 2 servers have /exactly/ the same net setups, and DNS/rbldnsd > configs. Yet no joy on the RELENG_7 box. So it /appears/ something > in this area has changed since 6. But I'm unable to discover any > info on it. > > Thank you for all your time and consideration. What subnet mask did you use when creating the 127.0.0.2 (etc) interfaces on lo0? On 7.0-R, I just ifconfig'ed 127.0.0.2 as an alias to lo0 with a subnet mask of 255.255.255.255, and I was able to bind/listen/accept on it with no problem. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
INET6 required for SCTP in 7.0?
Hi there, I'm not interested in enabling support for IPv6 for now. When I remove INET6 from the kernel configuration, I cannot compile the kernel without disabling SCTP. With fresh 7.0-STABLE source, here's the error output (INET6 disabled, but SCTP enabled): uipc_syscalls.o(.text+0x3c1): In function `sctp_generic_recvmsg': /usr/src/sys/kern/uipc_syscalls.c:2608: undefined reference to `sctp_sorecvmsg' uipc_syscalls.o(.text+0x21a2): In function `sctp_generic_sendmsg_iov': /usr/src/sys/kern/uipc_syscalls.c:2486: undefined reference to `sctp_lower_sosend' uipc_syscalls.o(.text+0x249d): In function `sctp_generic_sendmsg': /usr/src/sys/kern/uipc_syscalls.c:2379: undefined reference to `sctp_lower_sosend' uipc_syscalls.o(.text+0x266c): In function `sctp_peeloff': /usr/src/sys/kern/uipc_syscalls.c:2246: undefined reference to `sctp_can_peel_off' uipc_syscalls.o(.text+0x28e6):/usr/src/sys/kern/uipc_syscalls.c:2287: undefined reference to `sctp_do_peeloff' rtsock.o(.text+0xb7d): In function `rt_newaddrmsg': /usr/src/sys/net/rtsock.c:897: undefined reference to `sctp_addr_change' in_proto.o(.data+0xa8): undefined reference to `sctp_input' in_proto.o(.data+0xb0): undefined reference to `sctp_ctlinput' in_proto.o(.data+0xb4): undefined reference to `sctp_ctloutput' in_proto.o(.data+0xbc): undefined reference to `sctp_init' in_proto.o(.data+0xc8): undefined reference to `sctp_drain' in_proto.o(.data+0xcc): undefined reference to `sctp_usrreqs' in_proto.o(.data+0xdc): undefined reference to `sctp_input' in_proto.o(.data+0xe4): undefined reference to `sctp_ctlinput' in_proto.o(.data+0xe8): undefined reference to `sctp_ctloutput' in_proto.o(.data+0xfc): undefined reference to `sctp_drain' in_proto.o(.data+0x100): undefined reference to `sctp_usrreqs' in_proto.o(.data+0x110): undefined reference to `sctp_input' in_proto.o(.data+0x118): undefined reference to `sctp_ctlinput' in_proto.o(.data+0x11c): undefined reference to `sctp_ctloutput' in_proto.o(.data+0x130): undefined reference to `sctp_drain' in_proto.o(.data+0x134): undefined reference to `sctp_usrreqs' Is this intended and/or a known issue? Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possibility for FreeBSD 4.11 Extended Support
On Fri, 29 Dec 2006, Wilko Bulte wrote: > On Fri, Dec 29, 2006 at 08:45:03AM +0800, lveax wrote.. > > seems there are many machines at freebsd.org network are still using > > 4-STABLE now. > > There is a mix of versions in use, upgrading is done at the discretion > of the admins team that controls the FreeBSD.org server farm. That in > turn is dependent on the amount of time admins have available etc etc. > > So what is the problem? Indeed...I still run and admin a large number of 4-STABLE servers, and even as I'm currently in the process of deploying 6-STABLE on my own servers, I still regularly deploy 4-STABLE for customers of mine. There's a lot to be said for the "why fix what isn't broken" train of thought. I bet there are still a decent number of 2.2.8 boxes floating around...perhaps there's even more to be said for version maturity in general. I was hoping to wait for 6.4-R before jumping to the 6 line, but 6.2 is looking pretty solid for my purposes, so it seems like a great time to start migrating. I'm curious if anybody else is planning to migrate a large number of 4-STABLE boxes to 6-STABLE as of 6.2-R. Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggestions for Adaptec SAS AIC9410
On Fri, 9 Jun 2006, Scott Long wrote: > Doug White wrote: > > On Mon, 5 Jun 2006, Andy Dills wrote: > > > > > > > > I'm trying to get a Supermicro 6024H-32R setup with 6.1, but I'm > > > discovering that the Adaptec SAS AIC9410 controller isn't yet supported. > > > > > > I see one brief thread about it on this mailing list back in March, but no > > > further mention or conclusive details. There was talk of MFCing the mpt > > > driver...is anybody using this in production? > > > > > > Can you get a pciconf -lv off this system? It might just be a case of > > needing to add an ID to an existing driver (aac?). > > > > No, the 9410 is a SAS HBA chip. It's actually meant to be used just in > Adaptec HostRAID (software RAID) mode, but writing a standalone driver > is possible, albeit fairly difficult and time consuming. Being completely ignorant of the deep internals of the FreeBSD kernel, the GEOM layer, etc., how difficult is it to take the existing linux drivers that Adaptec distributes and port them to FreeeBSD? I ask out of curiousity, not implying that it isn't difficult and time consuming. Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Suggestions for Adaptec SAS AIC9410
I'm trying to get a Supermicro 6024H-32R setup with 6.1, but I'm discovering that the Adaptec SAS AIC9410 controller isn't yet supported. I see one brief thread about it on this mailing list back in March, but no further mention or conclusive details. There was talk of MFCing the mpt driver...is anybody using this in production? I'd prefer to use FreeBSD, but I'm guessing I'm going to need to do SuSE for this box, which Adaptec provides drivers for. Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
