Re: What's new on the 127.0.0/24 block in 7?
Quoting Mark Andrews [EMAIL PROTECTED]:
Quoting Mark Andrews [EMAIL PROTECTED]:
Quoting Andy Dills [EMAIL PROTECTED]:
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 t
o
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 determi
ne
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
Precisely! Sorry I apparently wasn't clearer in the beginning.
According to my conversations with the author of rbldnsd, rbldnsd was
returning REFUSED to all my requests on my FBSD-7 server.
Because it was unable to communicate on 127.0.0.2.
If it returned REFUSED it could communicate. REFUSED is a
DNS rcode so the packet went to the server and a reply was
returned. This is a problem with a access control list in
the rbldnsd configuration. I can tell you that without
ever having run rbldnsd.
Yes, of course. Sorry, my bad. RBLDNSD's /log/ files contain REFUSED.
The dig, host,nslookup queries return
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 58463
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
Sorry. I should have taken more time to answer.
--Chris H
Which doesn't change the diagnosis.
You are talking to the caching server which is talking to
rbldnsd which returns REFUSED. When the caching server
runs out of servers to try it returns SERVFAIL to the
original querier.
Hello Mark. Thank you for your thoughtful reply.
FWIW I'm hosting my own zone, out of my domain's address using a
different host name. I'm simply forwarding the requests to a different
port, so as to prevent port collision with the BIND. The zones are
answered our of 127.0.0.2 || 3.
I have absolutely no idea why FBSD v7 (on 2 machines) will only
dole out 127.0.0.1, while all my other servers running RELENG_6 all
dole out a /minimum/ of 127.0.0.1/8 by default. But, having just now
modified the default rc for ifconfig_lo0 to a 255.255.255.0 netmask
now makes a different response when querying rbldnsd.
Sending:
dig -p530 @my-domain.COM \
some IP in the zone.blackhole.my-domain.COM
now returns:
;; Got answer:
;; -HEADER- opcode: QUERY, status: REFUSED, id: 1673
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
The following query:
dig -p530 +norec @blackhole.my-domain.COM \
some IP in the zone.blackhole.my-domain.COM -t txt
Returns the same. So, adding the additional addresses on lo0
at least eliminated the NXDOMAIN. But of course, still no joy.
OH, and no, I'm not using an auth file (zone). Didn't need one
on the working v6 server, and see no reason to think I should
need one here.
Thank you again, for your thoughtful response.
--Chris H
P.S. Right out of the BIND FAQ:
zone blackhole.my-domain.COM {
type forward;
forward only;
forwarders { my servers primary IP port 530; };
};
P.S. you can test the rbldnsd directly if you want.
dig -p port +norec @address query
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--
panic: kernel trap (ignored)
___
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?
Hi Xin LI! On Mon, 03 Mar 2008 16:50:33 -0800; Xin LI wrote about 'Re: INET6 required for SCTP in 7.0?': 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): Yes, INET6 is (currently) required if you enable SCTP. Will it be fixed? Any time soon? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED] [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ 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?
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. What evidence do you have for this? Show your ifconfig commands, etc. I use 127/8 addresses all the time without problems. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jerky mouse still in 7.0-RELEASE
Eric L. Chen wrote: Hi Kris, I have this problem, too. If moused is enabled, use /dev/sysmouse in xorg.conf, X11 will freeze if mouse not moving. If moused is disabled, use /dev/psm0 in xorg.conf. Every thing works fine. I am running 7-STATBEL/i386. OK, please start a new thread so we don't confuse the issue further. Kris ___ 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 Tue, Mar 04, 2008 at 12:03:20AM -0800, Chris H. wrote: I have absolutely no idea why FBSD v7 (on 2 machines) will only dole out 127.0.0.1, while all my other servers running RELENG_6 all dole out a /minimum/ of 127.0.0.1/8 by default. But, having just now modified the default rc for ifconfig_lo0 to a 255.255.255.0 netmask now makes a different response when querying rbldnsd. Okay, let's back up here. The reason your FreeBSD machines don't respond on addresses other than 127.0.0.1 is because your lo0 interface does not have 127.0.0.2 and 127.0.0.3 addresses bound to them. These are called IP aliases. To add them, do the following: # ifconfig lo0 inet 127.0.0.2 netmask 255.255.255.255 alias # ifconfig lo0 inet 127.0.0.3 netmask 255.255.255.255 alias The netmask specified on an alias line is important! Use what I showed; do not argue. And yes, Linux does it differently. To make this work on bootup, add the following to rc.conf: ifconfig_lo0_alias0=inet 127.0.0.2 netmask 255.255.255.255 ifconfig_lo0_alias1=inet 127.0.0.3 netmask 255.255.255.255 You do not need an ifconfig_lo0 line in /etc/rc.conf; there is already one in /etc/defaults/rc.conf which will be used correctly. Secondly, on both RELENG_6 and RELENG_7, when the 127.0.0.1 address is assigned to lo0, the netmask used is 255.0.0.0. Evidence: $ uname -r 6.3-PRERELEASE $ grep lo0 /etc/rc.conf $ grep lo0 /etc/defaults/rc.conf ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. #ifconfig_lo0_alias0=inet 127.0.0.254 netmask 0x # Sample alias entry. $ ifconfig lo0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 $ uname -r 7.0-STABLE $ grep lo0 /etc/rc.conf $ grep lo0 /etc/defaults/rc.conf ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. #ifconfig_lo0_alias0=inet 127.0.0.254 netmask 0x # Sample alias entry. $ ifconfig lo0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff00 Thirdly, it's pretty apparent you don't understand what a netmask does. Machines don't dole out 127.0.0.1/8 -- this phrase makes no sense. A netmask is what defines a region of IP address space in which a machine within said region will honour packets within. More specifically: it tells the machine for any IP address you have bound to this interface, respond to packets destined to the broadcast address of that network region. For example, if you had a network region of 192.168.1.0/24 (in English, the region would be 192.168.1.0 to 192.168.1.255), your broadcast address would be 192.168.1.255. Your network address is 192.168.1.0, but that's for another discussion. If you put a machine on that network as 192.168.1.200, and give it a netmask of 255.255.255.0, it will respond to any packets destined to 192.168.1.100 (obviously), but will also respond to packets destined to the broadcast address (192.168.1.255). If you then put another box on the network as 192.168.1.7, and give it a netmask of 255.255.255.128 (/25), it should not be able to see 192.168.1.200. Broadcast packets from 192.168.1.7 would be going to 192.168.1.128 (its view of the network would be 192.168.1.0 to 192.168.1.128). This is a completely different beast than IP aliasing, but hopefully my explanation helps regardless. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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?
Quoting Kris Kennaway [EMAIL PROTECTED]: 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. What evidence do you have for this? Show your ifconfig commands, etc. Anything you like. I use 127/8 addresses all the time without problems. Yes, I have heard that from several people on the list. The only reference to lo0 I have is in /etc/defaults/rc.conf: ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. #ifconfig_lo0_alias0=inet 127.0.0.254 netmask 0x # Sample alias entry. #ifconfig_ed0_ipx=ipx 0x00010010# Sample IPX address family entry. #ifconfig_fxp0_name=net0# Change interface name from fxp0 to net0. #ipv4_addrs_fxp0=192.168.0.1/24 192.168.1.1-5/28 # example IPv4 address entry. Neither server has anything other than this. The RELENG_6 server acts as everyone else has responded (including yourself). But the 7-RC3 server, and 7-B4 server, both provide only 127.0.0.1 Dunno what to think. In my desperation to get this application running as it did on the RELENG_6 server; I added the following to /et/rc.conf ifconfig_lo0=inet 127.0.0.1 netmask 255.255.255.0 Killed the BIND, and then ran /etc/netstart and I discovered I have all the 127's I will ever need. I then restarted the BIND and the application I'm trying to get working. Anyhow. I didn't intend to spam the list with the application issues. I'm simply trying to discover why the loopback block isn't functioning the same on my recent 7 installs as it has always functioned in the past. I'll be happy to provide any further details/data anyone might require. Thanks for taking the time to respond. --Chris H Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ 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 Tue, Mar 04, 2008 at 01:52:46AM -0800, Jeremy Chadwick wrote: If you put a machine on that network as 192.168.1.200, and give it a netmask of 255.255.255.0, it will respond to any packets destined to 192.168.1.100 (obviously), but will also respond to packets destined to the broadcast address (192.168.1.255). Argh. The line: ... it will respond to any packets destined to 192.168.1.100 ... Should have read: ... it will respond to any packets destined to 192.168.1.200 ... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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 Tue, Mar 04, 2008 at 01:52:46AM -0800, Jeremy Chadwick wrote: If you then put another box on the network as 192.168.1.7, and give it a netmask of 255.255.255.128 (/25), it should not be able to see 192.168.1.200. Broadcast packets from 192.168.1.7 would be going to 192.168.1.128 (its view of the network would be 192.168.1.0 to 192.168.1.128). And this is also wrong (off-by-one on the broadcast address). It should have read: If you then put another box on the network as 192.168.1.7, and give it a netmask of 255.255.255.128 (/25), it should not be able to see 192.168.1.200. Broadcast packets from 192.168.1.7 would be going to 192.168.1.127 (its view of the network would be 192.168.1.0 to 192.168.1.127). This is what I get for handling two MPLS network outages at the same time while trying to write this mail. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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 Tue, 2008-03-04 at 00:03 -0800, Chris H. wrote: Hello Mark. Thank you for your thoughtful reply. FWIW I'm hosting my own zone, out of my domain's address using a different host name. I'm simply forwarding the requests to a different port, so as to prevent port collision with the BIND. The zones are answered our of 127.0.0.2 || 3. I have absolutely no idea why FBSD v7 (on 2 machines) will only dole out 127.0.0.1, while all my other servers running RELENG_6 all dole out a /minimum/ of 127.0.0.1/8 by default. This makes absolutely no sense. My FreeBSD 7 laptop has lo0 configured as 127.0.0.1/8 - THAT IS TO SAY, it has an IP address of 127.0.0.1 and a netmask of 255.0.0.0 . All other 7 boxes I test have the same, as do all the 6.1, 6.2 and 6.3 boxes. Pray, what netmask does your lo0 have, given that you insist it has 127.0.0.1/32 ? This would show up in ``ifconfig lo0'' as inet 127.0.0.1 netmask 0x I very much doubt it is. Tom signature.asc Description: This is a digitally signed message part
Re: What's new on the 127.0.0/24 block in 7?
Quoting Jeremy Chadwick [EMAIL PROTECTED]: On Tue, Mar 04, 2008 at 12:03:20AM -0800, Chris H. wrote: I have absolutely no idea why FBSD v7 (on 2 machines) will only dole out 127.0.0.1, while all my other servers running RELENG_6 all dole out a /minimum/ of 127.0.0.1/8 by default. But, having just now modified the default rc for ifconfig_lo0 to a 255.255.255.0 netmask now makes a different response when querying rbldnsd. Okay, let's back up here. The reason your FreeBSD machines don't respond on addresses other than 127.0.0.1 is because your lo0 interface does not have 127.0.0.2 and 127.0.0.3 addresses bound to them. These are called IP aliases. To add them, do the following: # ifconfig lo0 inet 127.0.0.2 netmask 255.255.255.255 alias # ifconfig lo0 inet 127.0.0.3 netmask 255.255.255.255 alias The netmask specified on an alias line is important! Use what I showed; do not argue. And yes, Linux does it differently. To make this work on bootup, add the following to rc.conf: ifconfig_lo0_alias0=inet 127.0.0.2 netmask 255.255.255.255 ifconfig_lo0_alias1=inet 127.0.0.3 netmask 255.255.255.255 You do not need an ifconfig_lo0 line in /etc/rc.conf; there is already one in /etc/defaults/rc.conf which will be used correctly. Secondly, on both RELENG_6 and RELENG_7, when the 127.0.0.1 address is assigned to lo0, the netmask used is 255.0.0.0. Evidence: $ uname -r 6.3-PRERELEASE $ grep lo0 /etc/rc.conf $ grep lo0 /etc/defaults/rc.conf ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. #ifconfig_lo0_alias0=inet 127.0.0.254 netmask 0x # Sample alias entry. $ ifconfig lo0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 $ uname -r 7.0-STABLE $ grep lo0 /etc/rc.conf $ grep lo0 /etc/defaults/rc.conf ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. #ifconfig_lo0_alias0=inet 127.0.0.254 netmask 0x # Sample alias entry. $ ifconfig lo0 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff00 Thirdly, it's pretty apparent you don't understand what a netmask does. Machines don't dole out 127.0.0.1/8 -- this phrase makes no sense. A netmask is what defines a region of IP address space in which a machine within said region will honour packets within. More specifically: it tells the machine for any IP address you have bound to this interface, respond to packets destined to the broadcast address of that network region. For example, if you had a network region of 192.168.1.0/24 (in English, the region would be 192.168.1.0 to 192.168.1.255), your broadcast address would be 192.168.1.255. Your network address is 192.168.1.0, but that's for another discussion. If you put a machine on that network as 192.168.1.200, and give it a netmask of 255.255.255.0, it will respond to any packets destined to 192.168.1.100 (obviously), but will also respond to packets destined to the broadcast address (192.168.1.255). If you then put another box on the network as 192.168.1.7, and give it a netmask of 255.255.255.128 (/25), it should not be able to see 192.168.1.200. Broadcast packets from 192.168.1.7 would be going to 192.168.1.128 (its view of the network would be 192.168.1.0 to 192.168.1.128). This is a completely different beast than IP aliasing, but hopefully my explanation helps regardless. OK, OK. deep breath. Sorry for all the noise. I've been struggling with all this for w-a-y too long, and am w-a-y too keyed up over it. I'm /not/ being concise, I'm making no sense at all. Sorry. To the point; Indeed, I fully understand all of this - no, /really/. :) I've been managing IP blocks for as long as I can remember (or care to), and yes, everything you thoughtfully explained is absolutely correct. I know. What I am having absolutely no understanding of; is why do 2 FBSD servers sharing the same setups, and the same stock lo0 setups react /completely/ differently than each other, when the only difference is the version of FBSD, and the version of the BIND? RELENG_6 server has nothing more than the 7-RC3 regarding lo0 (/etc/defaults/rc.conf: ifconfig_lo0=inet 127.0.0.1). when I start rbldnsd on the RELENG_6's primary IP port:530 with a zone file using 127.0.0.2 a zone file using 127.0.0.3. Everything works like a charm. Yet same setup, same config, different FBSD version; nothing works as it did before. What magic occurred on the RELENG_6 boxen? I have spent 5 days attempting to ascertain this - to no avail. In my desperation, I came here, thinking there /must/ be something different that I am unable to see, or is perhaps, undocumented. I know; it defies all NET logic. But it /did/ and /will/ work /every/ time on the RELENG_6 boxen. Yet, there is no difference in the configs. Really, I'm not a NET idiot. I am (for the most part) happily managing some 200 domains, and with the exception of this little episode, having no trouble with their management at all.
Re: What's new on the 127.0.0/24 block in 7?
Quoting Tom Evans [EMAIL PROTECTED]: On Tue, 2008-03-04 at 00:03 -0800, Chris H. wrote: Hello Mark. Thank you for your thoughtful reply. FWIW I'm hosting my own zone, out of my domain's address using a different host name. I'm simply forwarding the requests to a different port, so as to prevent port collision with the BIND. The zones are answered our of 127.0.0.2 || 3. I have absolutely no idea why FBSD v7 (on 2 machines) will only dole out 127.0.0.1, while all my other servers running RELENG_6 all dole out a /minimum/ of 127.0.0.1/8 by default. This makes absolutely no sense. My FreeBSD 7 laptop has lo0 configured as 127.0.0.1/8 - THAT IS TO SAY, it has an IP address of 127.0.0.1 and a netmask of 255.0.0.0 . All other 7 boxes I test have the same, as do all the 6.1, 6.2 and 6.3 boxes. Pray, what netmask does your lo0 have, given that you insist it has 127.0.0.1/32 ? This would show up in ``ifconfig lo0'' as inet 127.0.0.1 netmask 0x I very much doubt it is. Hello, and thanks for the reply. In short; yes, the 7-RC3 returned just that. In long; Both servers have the same (and only) entry: /etc/defaults/rc.conf: ifconfig_lo0=inet 127.0.0.1 no more, no less. The RELENG_6 server reports: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00inet6 ::1 prefixlen 128inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 The 7-RC3 did not (I'd provide the output, but I've since added and activated an entry in /etc/rc.conf that provides a /24 on lo0). Since I'm only /really/ interested in SWIP'ing 3 IP's out of the the block 254 will be more than enough. I don't know what to say. It's (as you've no doubt already discovered) driving me nuts! Anyhow, thanks again for taking the time to respond. I appreciate it. --Chris H Tom -- panic: kernel trap (ignored) ___ 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 Tue, Mar 04, 2008 at 02:23:21AM -0800, Chris H. wrote: What I am having absolutely no understanding of; is why do 2 FBSD servers sharing the same setups, and the same stock lo0 setups react /completely/ differently than each other, when the only difference is the version of FBSD, and the version of the BIND? RELENG_6 server has nothing more than the 7-RC3 regarding lo0 (/etc/defaults/rc.conf: ifconfig_lo0=inet 127.0.0.1). when I start rbldnsd on the RELENG_6's primary IP port:530 with a zone file using 127.0.0.2 a zone file using 127.0.0.3. Everything works like a charm. Yet same setup, same config, different FBSD version; nothing works as it did before. This is bordering on not enough information, sadly. People are going to need to see the details you're holding back. Start with providing the output from ifconfig lo0 on both the RELENG_6 box and the RELENG_7 box. Secondly, as Mark (Andrews) pointed out, whatever data you have in your rbldnsd **zone files** has nothing to do with the IP or IPs bound to lo0. What's really needed at this point is for you to describe in detail your rdnsbld configuration on both machines, and what it is you want to accomplish. As it stands right now, my understanding is that you are: * Running a single instance of rbldnsd on both machines, * Binding rbldnsd on each machine to publicip:530 * Utilising zone data which contains IPs 127.0.0.2 and 127.0.0.3 And that the setup works OK for you on RELENG_6, but not RELENG_7. I really don't want to have to install rbldnsd on both of our production RELENG_6 and RELENG_7 boxes to tinker with this and figure out what's going on, but if I have to, I will. I can assure you that both of our said boxes are identical when it comes to the behaviour of loopback; nothing there has changed. I didn't mean to imply you're stupid or incompetent -- that is in no way what I was getting at. But there does seem to be some disconnection going on: it's important that you understand A records or PTR records in zone files (which is what those 127.0.0.[23] addresses are) do not have direct relation to IP addresses bound to interfaces nor netmasks. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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 Tue, Mar 04, 2008 at 02:48:31AM -0800, Chris H. wrote: In long; Both servers have the same (and only) entry: /etc/defaults/rc.conf: ifconfig_lo0=inet 127.0.0.1 no more, no less. The RELENG_6 server reports: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 The 7-RC3 did not (I'd provide the output, but I've since added and activated an entry in /etc/rc.conf that provides a /24 on lo0). Since I'm only /really/ interested in SWIP'ing 3 IP's out of the the block 254 will be more than enough. Okay so it sounds like there's two separate issues here: 1) The issue with rbldnsd not working for you on RELENG_7 (returning REFUSED and some other oddities), 2) When assigning an IP to lo0 on your RELENG_7 box, the netmask chosen is 255.255.255.255 (0x) instead of 255.0.0.0 (0xff00), even though for everyone else this isn't happening. :-) You've made a hackfix for the issue in #2 by explicitly putting the following line in your /etc/rc.conf: ifconfig_lo0=inet 127.0.0.1 netmask 255.0.0.0 Which also appears to resolve issue #1, is that correct? If that's true, there is greater demons at work here, or something we aren't being told about the configuration. Again, the IPs in rbldnsd zone files have nothing to do with IP addresses or netmasks associated with loopback, so I don't see how changing the netmask would fix that. It almost sounds as if the rbldnsd software may be written to assume they're all related, and I sure hope that isn't the case. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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?
Quoting Jeremy Chadwick [EMAIL PROTECTED]: On Tue, Mar 04, 2008 at 02:23:21AM -0800, Chris H. wrote: What I am having absolutely no understanding of; is why do 2 FBSD servers sharing the same setups, and the same stock lo0 setups react /completely/ differently than each other, when the only difference is the version of FBSD, and the version of the BIND? RELENG_6 server has nothing more than the 7-RC3 regarding lo0 (/etc/defaults/rc.conf: ifconfig_lo0=inet 127.0.0.1). when I start rbldnsd on the RELENG_6's primary IP port:530 with a zone file using 127.0.0.2 a zone file using 127.0.0.3. Everything works like a charm. Yet same setup, same config, different FBSD version; nothing works as it did before. This is bordering on not enough information, sadly. People are going to need to see the details you're holding back. No. It's not a matter of holding back. I really don't want to spam the stable list with ports litter. My main concern/question was in figuring out why 2 identical server configs would react so differently in the way they handle lo0 and friends - rbldnsd, or no rbldnsd. Start with providing the output from ifconfig lo0 on both the RELENG_6 box and the RELENG_7 box. I've already committed an /etc/rc.conf: ifconfig_lo0=inet 127.0.0.1 netmask 255.255.255.0 which is now active on the 7-RC3 server. So until later I can only provide the RELENG_6 output: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00inet6 ::1 prefixlen 128inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 I'll uncommit/unactivate the 7-RC3 entry as soon as I can and provide it's output, as well. Secondly, as Mark (Andrews) pointed out, whatever data you have in your rbldnsd **zone files** has nothing to do with the IP or IPs bound to lo0. What's really needed at this point is for you to describe in detail your rdnsbld configuration on both machines, and what it is you want to accomplish. As it stands right now, my understanding is that you are: * Running a single instance of rbldnsd on both machines, * Binding rbldnsd on each machine to publicip:530 * Utilising zone data which contains IPs 127.0.0.2 and 127.0.0.3 Actually, I'm only running rbldnsd on one machine at a time. With the final goal of running it permanently on the 7-RC3 (current work in progress). And that the setup works OK for you on RELENG_6, but not RELENG_7. Correct. I really don't want to have to install rbldnsd on both of our production RELENG_6 and RELENG_7 boxes to tinker with this and figure out what's going on, but if I have to, I will. No. Please don't bother yourself with this. This wasn't meant to be the topic of this thread - it's just the situation that brought me to my question(s) regarding the behavior of lo0 and friends. Thank you for considering it though. :) I can assure you that both of our said boxes are identical when it comes to the behaviour of loopback; nothing there has changed. Fair enough. My RELENG_6 boxen must be demon possessed, or something - D'OH! Pardon the pun. :P I didn't mean to imply you're stupid or incompetent -- that is in no way what I was getting at. But there does seem to be some disconnection going on: it's important that you understand A records or PTR records in zone files (which is what those 127.0.0.[23] addresses are) do not have direct relation to IP addresses bound to interfaces nor netmasks. No. Just the ability to create/connect/communicate over them (the IP's). Which it seems the RELENG_6 server is happy to provide - inspite of how unorthodox it is. Thank you very much for all the time you've taken. --Chris H -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ 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?
Quoting Jeremy Chadwick [EMAIL PROTECTED]: On Tue, Mar 04, 2008 at 02:48:31AM -0800, Chris H. wrote: In long; Both servers have the same (and only) entry: /etc/defaults/rc.conf: ifconfig_lo0=inet 127.0.0.1 no more, no less. The RELENG_6 server reports: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 The 7-RC3 did not (I'd provide the output, but I've since added and activated an entry in /etc/rc.conf that provides a /24 on lo0). Since I'm only /really/ interested in SWIP'ing 3 IP's out of the the block 254 will be more than enough. Okay so it sounds like there's two separate issues here: 1) The issue with rbldnsd not working for you on RELENG_7 (returning REFUSED and some other oddities), 2) When assigning an IP to lo0 on your RELENG_7 box, the netmask chosen is 255.255.255.255 (0x) instead of 255.0.0.0 (0xff00), even though for everyone else this isn't happening. :-) You've made a hackfix for the issue in #2 by explicitly putting the following line in your /etc/rc.conf: ifconfig_lo0=inet 127.0.0.1 netmask 255.0.0.0 Which also appears to resolve issue #1, is that correct? Yes, adding an entry in /etc/rc.conf that provides 254 IP's now reveals: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST 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 that's true, there is greater demons at work here, LOL. By the time you read this, you will have already read my /punny/ statement to the same. :) or something we aren't being told about the configuration. Again, the IPs in rbldnsd zone files have nothing to do with IP addresses or netmasks associated with loopback, so I don't see how changing the netmask would fix that. It almost sounds as if the rbldnsd software may be written to assume they're all related, and I sure hope that isn't the case. No. I'm more inclined, at this state. To think that since the IP is defined in the zone file. That it requires the /availability/ of the IP so that it can use it - not unlike the BIND. But, it is not the BIND, so will have it's own (see; different) way of management regarding IP--name, etc... Anyway, my /real/ reason for starting all this, was to figure out why the 2 machines act so differently. I can assure you that I have spent the entire day attempting to figure out if any difference had crept into any of the server configs. But could find none. Thanks again for all your time and effort. --Chris H -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
linked ssl libraries to binary
I have a freebsd 6.3 server and a freebsd 7.0 server, I have a binary I run of the freebsd 7 box but has recently been crashing, the binary in question is ezbounce. It was previously running for weeks no problems at all and then during the past 2 weeks or so its had problems. Like many shell programs it has a configure script and you then run make or gmake to compile the binary. On freebsd 6 it picks up /usr/local ssl libaries no problem and in fact uses them without even haveing to specify the directory it auto detects them over the base ssl. On freebsd 7 it uses the base libraries even when telling it to search in /usr/local. So I then decided to move the binary I compiled on freebsd 6 over to the freebsd 7 box and when I ran ldd on the binary to my surprise it is using the base libraries on freebsd 7. ldd on binary on freebsd 6 libssl.so.5 = /usr/local/lib/libssl.so.5 (0x48102000) libcrypto.so.5 = /usr/local/lib/libcrypto.so.5 (0x48143000) libcrypt.so.3 = /lib/libcrypt.so.3 (0x4829f000) libboost_iostreams.so = /usr/local/lib/libboost_iostreams.so (0x482b8000) libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x482c) libm.so.4 = /lib/libm.so.4 (0x48396000) libpthread.so.2 = /lib/libpthread.so.2 (0x483ac000) libc.so.6 = /lib/libc.so.6 (0x483d3000) libbz2.so.2 = /usr/lib/libbz2.so.2 (0x484cb000) libz.so.3 = /lib/libz.so.3 (0x484dc000) ldd on same binary on freebsd 7 libssl.so.5 = /usr/lib/libssl.so.5 (0x28101000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x28142000) libcrypt.so.3 = /usr/local/lib/compat/libcrypt.so.3 (0x2829a000) libboost_iostreams.so = /usr/local/lib/libboost_iostreams.so (0x282b2000) libstdc++.so.5 = /usr/local/lib/compat/libstdc++.so.5 (0x282bd000) libm.so.4 = /usr/local/lib/compat/libm.so.4 (0x28388000) libpthread.so.2 = /usr/local/lib/compat/libpthread.so.2 (0x2839e000) libc.so.6 = /usr/local/lib/compat/libc.so.6 (0x283c3000) libc.so.7 = /lib/libc.so.7 (0x284a9000) libbz2.so.3 = /usr/lib/libbz2.so.3 (0x285a4000) libz.so.4 = /lib/libz.so.4 (0x285b4000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x285c6000) libm.so.5 = /lib/libm.so.5 (0x286ba000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x286cf000) libthr.so.3 = /lib/libthr.so.3 (0x286da000) The binary doesnt run on the freebsd 7 either it coredumps even tho I have compat6x installed, typically in the past I have had no problems at all using binaries compiled on old freebsd versions on newer versions I just had to install the appropriate compat package. Here is the ldd when compiled on the freebsd 7 box libssl.so.5 = /usr/lib/libssl.so.5 (0x2810f000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x2815) libcrypt.so.4 = /lib/libcrypt.so.4 (0x282a8000) libboost_iostreams.so = /usr/local/lib/libboost_iostreams.so (0x282c1000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x282cc000) libm.so.5 = /lib/libm.so.5 (0x283c) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x283d5000) libthr.so.3 = /lib/libthr.so.3 (0x283e) libc.so.7 = /lib/libc.so.7 (0x283f3000) libbz2.so.3 = /usr/lib/libbz2.so.3 (0x284ee000) libz.so.4 = /lib/libz.so.4 (0x284fe000) Is the output for the ssl libraries skewed because both the local filenames and the base filenames are the same? as there is a /usr/local/lib/libssl.so.5 and a /usr/lib/libssl.so.5. Or does this mean that it really is linked against the base libraries as I am wondering how that is possible when the same binary is linked against different libraries on a different machine. Chris ___ 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?
Chris H. [EMAIL PROTECTED] writes: Yes, adding an entry in /etc/rc.conf that provides 254 IP's now reveals: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST 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. Let's peel this issue back to the basics. This does *not* have 254 IP addresses on that interface. The interface still has only one address on that interface. There are 254 other addresses on the subnet, but only one of them belongs to your machine. If you want the machine to answer to 127.0.0.2, you still need to add it separately. ___ 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?
Hi Xin LI! On Mon, 03 Mar 2008 16:50:33 -0800; Xin LI wrote about 'Re: INET6 required fo r SCTP in 7.0?': 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): Yes, INET6 is (currently) required if you enable SCTP. Will it be fixed? Any time soon? 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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linked ssl libraries to binary
On Tue, Mar 04, 2008 at 12:05:22PM +, Chris wrote: I have a freebsd 6.3 server and a freebsd 7.0 server, I have a binary I run of the freebsd 7 box but has recently been crashing, the binary in question is ezbounce. It was previously running for weeks no problems at all and then during the past 2 weeks or so its had problems. Like many shell programs it has a configure script and you then run make or gmake to compile the binary. You know there's /usr/ports/irc/ezbounce, right? Well, I suppose that only applies if you actually maintain/run the servers in question. But apparently you do (see below). So I then decided to move the binary I compiled on freebsd 6 over to the freebsd 7 box and when I ran ldd on the binary to my surprise it is using the base libraries on freebsd 7. This doesn't come as much of a surprise. The binary actually references libraries by names such as libXXX.so, not libXXX.so.NUMBER. ldd on binary on freebsd 6 libssl.so.5 = /usr/local/lib/libssl.so.5 (0x48102000) libcrypto.so.5 = /usr/local/lib/libcrypto.so.5 (0x48143000) libcrypt.so.3 = /lib/libcrypt.so.3 (0x4829f000) libboost_iostreams.so = /usr/local/lib/libboost_iostreams.so (0x482b8000) libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x482c) libm.so.4 = /lib/libm.so.4 (0x48396000) libpthread.so.2 = /lib/libpthread.so.2 (0x483ac000) libc.so.6 = /lib/libc.so.6 (0x483d3000) libbz2.so.2 = /usr/lib/libbz2.so.2 (0x484cb000) libz.so.3 = /lib/libz.so.3 (0x484dc000) ldd on same binary on freebsd 7 libssl.so.5 = /usr/lib/libssl.so.5 (0x28101000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x28142000) The libssl.so being used by the ezbounce binary you have, on RELENG_7, is using the base system's version. This is NOT compatible, AFAIK, as the libssl.so on RELENG_6. The same issue applies to libcrypto.so. libcrypt.so.3 = /usr/local/lib/compat/libcrypt.so.3 (0x2829a000) libboost_iostreams.so = /usr/local/lib/libboost_iostreams.so (0x282b2000) libstdc++.so.5 = /usr/local/lib/compat/libstdc++.so.5 (0x282bd000) libm.so.4 = /usr/local/lib/compat/libm.so.4 (0x28388000) libpthread.so.2 = /usr/local/lib/compat/libpthread.so.2 (0x2839e000) libc.so.6 = /usr/local/lib/compat/libc.so.6 (0x283c3000) libc.so.7 = /lib/libc.so.7 (0x284a9000) libbz2.so.3 = /usr/lib/libbz2.so.3 (0x285a4000) libz.so.4 = /lib/libz.so.4 (0x285b4000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x285c6000) libm.so.5 = /lib/libm.so.5 (0x286ba000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x286cf000) libthr.so.3 = /lib/libthr.so.3 (0x286da000) I can't explain what's with the double-linking of some libraries, e.g. two linked in-versions of libc, libm, libstdc++, and others. It's possible this is normal, but it seems like it would cause a crash. I do know that FreeBSD has some sort of internal version numbering for symbols in shared libraries, but I don't know if it was introduced in RELENG_7, or if RELENG_6 had it. If it's new as of RELENG_7, then I can see how a binary built on RELENG_6 _might_ call the wrong version of a function. nm(1) output would be able to help with this, I think. The binary doesnt run on the freebsd 7 either it coredumps even tho I have compat6x installed, typically in the past I have had no problems at all using binaries compiled on old freebsd versions on newer versions I just had to install the appropriate compat package. I would strongly recommend against relying on compat6x for anything that can be recompiled. I have never trusted the compat libraries, because I don't like to play risky business with multiple versions of a shared library on a machine (see below). You did not provide a crash dump or gdb output of the program, so it's hard to say where the actual crash (SSL, libc, libm, etc.) occurred. But then again, is it worth debugging when. Here is the ldd when compiled on the freebsd 7 box .you can recompile it? :-) You should be doing this anyways. So what's the problem -- or is this more of a I'm curious how ld.so works inquiry? Is the output for the ssl libraries skewed because both the local filenames and the base filenames are the same? as there is a /usr/local/lib/libssl.so.5 and a /usr/lib/libssl.so.5. Or does this mean that it really is linked against the base libraries as I am wondering how that is possible when the same binary is linked against different libraries on a different machine. I indirectly answered this in my 2nd paragraph. Welcome to the UNIX equivalent of DLL Hell on Windows -- and why you should *always* recompile programs when the major version of a shared library (.so) changes. I cannot stress this enough. All that said: you might be able to get around the problem in question by setting LD_LIBRARY_PATH=/usr/local/lib/compat when running the
Re: Analysis of disk file block with ZFS checksum error
Joe Peterson wrote: Gavin Atkinson wrote: Are the datestamps (Thu Jan 24 23:20:58 2008) found within the corrupt block before or after the datestamp of the file it was found within? i.e. was the corrupt block on the disk before or after the mp3 was written there? Hi Gavin, those dated are later than the original copy (I do not have the file timestamps to prove this, but according to my email record, I am pretty sure of this). So the corrupt block is later than the original write. If this is the case, I assume that the block got written, by mistake, into the middle of the mp3 file. Someone else suggested that it could be caused by a bad transfer block number or bad drive command (corrupted on the way to the drive, since these are not checksummed in the hardware). If the block went to the wrong place, AND if it was a HW glitch, I suppose the best ZFS could then do is retry the write (if its failure was even detected - still not sure if ZFS does a re-check of the disk data checksum after the disk write), not knowing until the later scrub that the block had corrupted a file. I think that anything is possible, but I know I was getting periodic DMA timeouts, etc. around that time. I hesitate, although it is tempting, to use this evidence to focus blame purely on bad HW, given that others seem to be seeing DMA problems too, and there is reasonable doubt whether their problems are HW related or not. In my case, I have been free of DMA errors (cross your fingers) after re-installed FreeBSD completely (giving it a larger boot partition and redoing the ZFS slice too), and before this, I changed the IDE cable just to eliminate one more variable. Therefore, there are too many variables to reach a firm conclusion, since even if the cable was bad, I never saw one DMA error or other indication of anything wrong with HW from the Linux side (and I've been using that HW with both Linux and FreeBSD 6.2 for months now - no apparent flakiness of any kind on either system). So either it *was* bad and FreeBSD 7.0 was being more honest, FreeBSD's drivers and/or ZFS was stressing the HW and revealing weaknesses in the cable, or it was a SW issue that got cleared somehow when I re-installed. Is it possible that the problem lies in the ATA drivers in FreeBSD or even in ZFS and just looks like HW issues? I do not have enough info/expertise to know. If not, then it may very well be true that HW problems are pretty widespread (and that disk HW cannot, in fact, be trusted), and there really *is* a strong need for ZFS *now* to protect our data. If there is a possibility that SW could be involved, any hints on how to further debug this would be of great help to those still experiencing recent DMA errors. I just want to be more sure one way or the other, but I know this issue is not an easy one (however, it's the kind of problem that should receive the highest priority, IMHO). I'm not sure what happened to this thread, but I also had a lot of similar issues. I was using SATA, and using a mirrored pair of SATA drives, brand new. It was suggested that my controller was junk. I'm starting to think there is a timing issue or some such problem with ZFS, since I can use the same drives in a gmirror with UFS, and never have any data problems (md5 checksums confirm it over-and-over). I highly doubt that everyone is seeing similar issues and it just is because ZFS is so intense. I've had plenty of systems under severe disk load that have never exhibited corrupt files because of something like this. I wish we could get our hands on this issue.. Seems like some common threads are ATA/SATA disks. Is your setup running 32bit or 64bit FreeBSD? (if you already mentioned it, I'm sorry, I missed it) Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Analysis of disk file block with ZFS checksum error
On Tue, Mar 04, 2008 at 07:25:35AM -0600, Eric Anderson wrote: I'm starting to think there is a timing issue or some such problem with ZFS, since I can use the same drives in a gmirror with UFS, and never have any data problems (md5 checksums confirm it over-and-over). I highly doubt that everyone is seeing similar issues and it just is because ZFS is so intense. I've had plenty of systems under severe disk load that have never exhibited corrupt files because of something like this. One thing that hasn't been mentioned (or maybe it has been but I missed it): FreeBSD's ZFS port is version 6, while Solaris is up to version 10. Is it possible that the problem folks are experiencing, including the infamous deadlock or crash on heavy I/O between UFS/UFS2 and ZFS filesystems, could've been fixed between versions 6 and 10? I myself use gstripe(8) and UFS2 (no softupdates) on two identical SATA disks. I do nightly backups so if I lose a disk, I'm OK. My transfer rates are quite good (~143MB/sec read, ~130MB/sec write -- really!) on the stripe, and in the past 2 weeks I have spent a LOT of time copying over 150GB of data back and forth between the stripe and the backup disk without any issues. All disks are on an ICH7 controller. I wish we could get our hands on this issue.. Seems like some common threads are ATA/SATA disks. Is your setup running 32bit or 64bit FreeBSD? (if you already mentioned it, I'm sorry, I missed it) So far the reports have shown that it's not specific to either i386 or amd64, and that it's not specific to any type of hardware (motherboard, controller, etc.). Joe's setup is very different from mine, for example. If the same disks are fine when used with UFS/UFS2, then I'd say it's less of a ATA subsystem bug, and more of an oddity with ZFS on FreeBSD. If it's reproducable, that would be helpful to developers. Regarding ATA/SATA though, there are reports of DMA timeouts and other oddities happening on ATA/SATA disks on FreeBSD. When I was using ZFS not too long ago, I experienced that problem when doing heavy I/O (copying data from a standard UFS2 disk to a ZFS RAIDZ pool). It's been the only time I've seen this problem. http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/040013.html The drive showed no signs of errors (SMART stats look fine, no mechanical noises or other oddities). I've since replaced it out of pure paranoia with a disk identical to the ones on the gstripe(8). Regarding those issues (DMA errors, etc.), Scott Long has offered to help, but needs systems which can reproduce the problem reliably and have remote access (serial highly recommended). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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 2008-03-04, Chris H. wrote: Yes, adding an entry in /etc/rc.conf that provides 254 IP's now reveals: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST 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. Anyway, my /real/ reason for starting all this, was to figure out why the 2 machines act so differently. I can assure you that I have spent the entire day attempting to figure out if any difference had crept into any of the server configs. But could find none. The fact that you could not find the difference(s) is no evidence that there are none. It's abundantly clear from this very lengthy and often almost content-free discussion that you are either so tired and frantic that your brain has seized up or that you really don't understand this stuff as well as you think. (The clear evidence is that you have no idea of the meaning of assigning and IP address to an interface versus the meaning of an IP address given as a reply to a name lookup -- yet you continue to insist that you do have such an understanding.) If you could give a clear and complete description of what is really happening, without any of your own theories clouding that description, somebody clueful might be able to see just what is the obvious factor you have missed. As things stand, you are just going around in big unproductive circles and giving the rest of us no useful information to help you with. None of the above is intended as a flame, but it's really time to take stock and make a serious attempt to provide all the data so that those who can help are able to understand the problem. Greg ___ 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 Tue, Mar 04, 2008 at 03:22:00AM -0800, Chris H. wrote: No. It's not a matter of holding back. I really don't want to spam the stable list with ports litter. My main concern/question was in figuring out why 2 identical server configs would react so differently in the way they handle lo0 and friends - rbldnsd, or no rbldnsd. Have you recently diffed the actual running config files? From the sidelines, it sounds like a change may have been made and forgotten, or made by another admin which could be causing issues. I know that often when I start thinking, Nothing is different the software is broken! something is different. Important files off the top of my head: /etc/defaults/rc.conf /etc/rc.conf /etc/rc.local /etc/namedb/named.conf (and friends) /usr/local/etc/whatever_rbldnsd_uses pkg_info | egrep '(rbldns|named)' and then diff that output. maybe diff the ifconfig -a output between the two boxes and verify the expected differences. I think more details might actually translate to less clutter on the -stable list, even if it turns out to be ports related. -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linked ssl libraries to binary
On Tue, Mar 04, 2008 at 05:18:02AM -0800, Jeremy Chadwick wrote: On Tue, Mar 04, 2008 at 12:05:22PM +, Chris wrote: This doesn't come as much of a surprise. The binary actually references libraries by names such as libXXX.so, not libXXX.so.NUMBER. This is incorrect. The binaries directly reference libXXX.so.NUMBER as reported using the first column of ldd output. ldd on same binary on freebsd 7 libssl.so.5 = /usr/lib/libssl.so.5 (0x28101000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x28142000) libcrypt.so.3 = /usr/local/lib/compat/libcrypt.so.3 (0x2829a000) libboost_iostreams.so = /usr/local/lib/libboost_iostreams.so (0x282b2000) libstdc++.so.5 = /usr/local/lib/compat/libstdc++.so.5 (0x282bd000) libm.so.4 = /usr/local/lib/compat/libm.so.4 (0x28388000) libpthread.so.2 = /usr/local/lib/compat/libpthread.so.2 (0x2839e000) libc.so.6 = /usr/local/lib/compat/libc.so.6 (0x283c3000) libc.so.7 = /lib/libc.so.7 (0x284a9000) libbz2.so.3 = /usr/lib/libbz2.so.3 (0x285a4000) libz.so.4 = /lib/libz.so.4 (0x285b4000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x285c6000) libm.so.5 = /lib/libm.so.5 (0x286ba000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x286cf000) libthr.so.3 = /lib/libthr.so.3 (0x286da000) Based on the above, the binary has direct references to (eg) libssl.so.5 (which is found in the base system on 7.x and therefore has embedded references to libc.so.7) and libcrypt.so.3 (which is a 6.x library and therefore has embedded references to libc.so.6). two linked in-versions of libc, libm, libstdc++, and others. It's possible this is normal, but it seems like it would cause a crash. This is very much abnormal and having an executable pull in two versions of a system library virtually guarantees that it won't work. I indirectly answered this in my 2nd paragraph. Welcome to the UNIX equivalent of DLL Hell on Windows -- and why you should *always* recompile programs when the major version of a shared library (.so) changes. I cannot stress this enough. Agreed. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpRYRCkVfqCt.pgp Description: PGP signature
7.0-Release and 3ware 9550SXU w/BBU - horrible write performance
Hi, I've got a new server with a 3ware 9550SXU with the Battery. I am using FreeBSD 7.0-Release (tried both 4BSD and ULE) using AMD64 and the 3ware performance for writes is just plain horrible. Something is obviously wrong but I'm not sure what. I've got a 4 disk RAID 10 array. According to 3dm2 the cache is on. I even tried setting The StorSave preference to Performance with no real benefit. There seems to be something really wrong with disk performance. Here's the results from bonnie: File './Bonnie.2551', size: 104857600 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 9989 4.8 6739 1.0 18900 7.8 225973 98.5 1914662 99.9 177210.7 259.7 Any ideas? Anybody have one of these that's working with FreeBSD 7? Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 7.9-stable: weird messages in /var/log/messages?
Hello One one of my stable machines I see these messages in /var/log/messages: Mar 3 18:37:41 kg-i82 kernel: 16.011e9e3975b3aa06 too long Mar 3 21:41:42 kg-i82 kernel: 16.016a24cf0742715c too long Mar 3 21:41:58 kg-i82 kernel: 15.feb784aee196608c too short Does anyone know hwat the messages mean, or which part of the kernel they are from? Googling didn't help me. The machine runs FreeBSD 7.0-stable: [EMAIL PROTECTED] uname -a FreeBSD kg-i82.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #1: Sun Mar 2 01:18:27 CET 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/I81K i386 and the complete /var/log/messages looks like this: [EMAIL PROTECTED] less /var/log/messages Mar 3 13:00:00 kg-i82 newsyslog[1323]: logfile turned over due to size100K Mar 3 18:37:41 kg-i82 kernel: 16.011e9e3975b3aa06 too long Mar 3 21:41:42 kg-i82 kernel: 16.016a24cf0742715c too long Mar 3 21:41:58 kg-i82 kernel: 15.feb784aee196608c too short Mar 4 15:01:04 kg-i82 dhclient: New IP Address (ral0): 10.1.150.14 Mar 4 15:01:04 kg-i82 dhclient: New Subnet Mask (ral0): 255.255.0.0 Mar 4 15:01:04 kg-i82 dhclient: New Broadcast Address (ral0): 10.1.255.255 Mar 4 15:01:04 kg-i82 dhclient: New Routers (ral0): 10.1.10.1 Mar 4 15:02:48 kg-i82 kernel: ral0: link state changed to DOWN Mar 4 15:04:03 kg-i82 kernel: ral0: link state changed to UP Mar 4 15:04:04 kg-i82 kernel: ral0: link state changed to DOWN Mar 4 15:04:06 kg-i82 kernel: ral0: link state changed to UP Mar 4 15:04:09 kg-i82 dhclient: New IP Address (ral0): 10.1.150.14 Mar 4 15:04:09 kg-i82 dhclient: New Subnet Mask (ral0): 255.255.0.0 Mar 4 15:04:09 kg-i82 dhclient: New Broadcast Address (ral0): 10.1.255.255 Mar 4 15:04:09 kg-i82 dhclient: New Routers (ral0): 10.1.10.1 Mar 4 19:30:04 kg-i82 su: tingo to root on /dev/ttyp0 The only unusual thing is that the machine has been booted verbose. -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.9-stable: weird messages in /var/log/messages?
Torfinn Ingolfsen wrote: Hello One one of my stable machines I see these messages in /var/log/messages: Mar 3 18:37:41 kg-i82 kernel: 16.011e9e3975b3aa06 too long Mar 3 21:41:42 kg-i82 kernel: 16.016a24cf0742715c too long Mar 3 21:41:58 kg-i82 kernel: 15.feb784aee196608c too short Does anyone know hwat the messages mean, or which part of the kernel they are from? Googling didn't help me. It is reporting large variations in the rate of your time clock (see kern_tc.c). Also, you appear to be emailing from the distant future. Please reply with stock tips :) Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-STABLE amd64 kernel trap during boot-time device probe
On Sun, Mar 02, 2008 at 07:04:29PM +1100, Peter Jeremy wrote: It looks like there's an unexpected ATA interrupt. I can't think of any reason why either sound or netgraph would cause this - neither should be touching the hardware directly. Unless someone else has seen this before, tracking it down could be time-consuming. I think you'll need a serial console to continue. Are you still mainly interested in the 'boot -v' output, or did you have something else in mind for the serial console? I looked over the 'remote GDB' section of the handbook, and I gather I'd need a second amd64 host for that, but I unfortunately don't. Jeff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Analysis of disk file block with ZFS checksum error
Eric Anderson wrote: I'm starting to think there is a timing issue or some such problem with ZFS, since I can use the same drives in a gmirror with UFS, and never have any data problems (md5 checksums confirm it over-and-over). I highly doubt that everyone is seeing similar issues and it just is because ZFS is so intense. I've had plenty of systems under severe disk load that have never exhibited corrupt files because of something like this. I also wondered this - i.e. if ZFS was triggering a certain timing behavior that revealed the problem. Still, if this is the case, it seems to me that the problem lies in the ATA subsystem, since it should prevent a higher-level things like ZFS to be able to create bad timings (or am I not thinking of this correctly?). Also, I think there were some reports of problems with DMA/ATA when *not* using ZFS. I wish we could get our hands on this issue.. Seems like some common threads are ATA/SATA disks. Is your setup running 32bit or 64bit FreeBSD? (if you already mentioned it, I'm sorry, I missed it) This was on 32bit FreeBSD with PATA. I am the one who had no SMART issues and no DMA errors reported under Linux. Changing the cable may have fixed it, since I did not see errors in some further testing, but even if so, my theory is that there is some edge case (timing?) that the FreeBSD ATA drivers were sensitive to, and perhaps my change of cables pushed the problem to the other side of the threshold. Since I never saw errors under Linux (and I've been using that cable for a couple of years), I do not necessarily think the cable was actually defective. -Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
OT: How to find mirror operator?
Hi, the web mirror www.de.freebsd.org seems to be about 6 weeks out of date. Does anybody know how to contact the server admin? Wolfgang ___ 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?
Quoting Lowell Gilbert [EMAIL PROTECTED]: Chris H. [EMAIL PROTECTED] writes: Yes, adding an entry in /etc/rc.conf that provides 254 IP's now reveals: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST 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. Let's peel this issue back to the basics. This does *not* have 254 IP addresses on that interface. The interface still has only one address on that interface. There are 254 other addresses on the subnet, but only one of them belongs to your machine. If you want the machine to answer to 127.0.0.2, you still need to add it separately. Yes. Of course. In the same way one might add /any/ address to their working pool - eg; ifconfig_lo0=inet 127.0.0.1 netmask 255.255.255.224 which could/might be followed by ifconfig_lo0_alias0=inet 127.0.0.2 netmask 255.255.255.255 etc... 127.0.0.0 - NET 127.0.0.255 - BCAST In spite of the way I announced/described all this, I'm actually familiar with the whole thing. My only interest was in determining why the netmask defaulted to 0x (255.255.255.255) on the lo0 interface in my 7-RC3 install. While all of my RELENG_6 servers happily provided 0xff00. After much examination, and research, I could find no apparent reason. So decided to ask here. Thank you for taking the time to respond. --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ 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?
Quoting Chris H. [EMAIL PROTECTED]: Quoting Lowell Gilbert [EMAIL PROTECTED]: Chris H. [EMAIL PROTECTED] writes: Yes, adding an entry in /etc/rc.conf that provides 254 IP's now reveals: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST 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. Let's peel this issue back to the basics. This does *not* have 254 IP addresses on that interface. The interface still has only one address on that interface. There are 254 other addresses on the subnet, but only one of them belongs to your machine. If you want the machine to answer to 127.0.0.2, you still need to add it separately. Yes. Of course. In the same way one might add /any/ address to their working pool - eg; ifconfig_lo0=inet 127.0.0.1 netmask 255.255.255.224 which could/might be followed by ifconfig_lo0_alias0=inet 127.0.0.2 netmask 255.255.255.255 etc... 127.0.0.0 - NET 127.0.0.255 - BCAST strike127.0.0.255 - BCAST/strike 127.0.0.31 - BCAST In spite of the way I announced/described all this, I'm actually familiar with the whole thing. Then why did you claim 255 addresses on a /27 in your post. My only interest was in determining why the netmask defaulted to 0x (255.255.255.255) on the lo0 interface in my 7-RC3 install. While all of my RELENG_6 servers happily provided 0xff00. After much examination, and research, I could find no apparent reason. So decided to ask here. Thank you for taking the time to respond. --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linked ssl libraries to binary
On Wed, Mar 05, 2008 at 05:23:15AM +1100, Peter Jeremy wrote: On Tue, Mar 04, 2008 at 05:18:02AM -0800, Jeremy Chadwick wrote: On Tue, Mar 04, 2008 at 12:05:22PM +, Chris wrote: This doesn't come as much of a surprise. The binary actually references libraries by names such as libXXX.so, not libXXX.so.NUMBER. This is incorrect. The binaries directly reference libXXX.so.NUMBER as reported using the first column of ldd output. I stand corrected; one can even confirm it by using strings on the binary: $ strings /usr/local/bin/webalizer | grep 'lib.*\.so' /libexec/ld-elf.so.1 libgd.so.4 libpng.so.5 libz.so.3 libm.so.4 libc.so.6 Thanks for correcting me! Learn something new all the time... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
X11 will freeze when moused enabled
Hi All, I create a new thread to discuss X11 freeze when moused enabled and mouse stillness. I am running 7-STATBEL/i386, March 2, 2008 (UTC) cvsup'd. In my test, i) moused enabled, use /dev/sysmouse in xorg.conf, X11 will freeze if mouse not moving. ii) moused disabled, use /dev/psm0 in xorg.conf. Every thing works fine. iii) moused disabled, use Bluetooth mouse, use /dev/sysmouse (bthidd write mouse event to /dev/sysmouse directly) in xorg.conf, works fine. So, I think this problem is caused by moused. Since bthidd and X11 can handle mouse events with /dev/sysmouse properly. But moused and X11 cannot work with /ev/sysmouse. /Eric ___ 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?
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=8049UP,LOOPBACK,RUNNING,MULTICAST 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. Anyway, my /real/ reason for starting all this, was to figure out why the 2 machines act so differently. I can assure you that I have spent the entire day attempting to figure out if any difference had crept into any of the server configs. But could find none. The fact that you could not find the difference(s) is no evidence that there are none. It's abundantly clear from this very lengthy and often almost content-free discussion that you are either so tired and frantic that your brain has seized up or that you really don't understand this stuff as well as you think. (The clear evidence is that you have no idea of the meaning of assigning and IP address to an interface versus the meaning of an IP address given as a reply to a name lookup -- yet you continue to insist that you do have such an understanding.) If you could give a clear and complete description of what is really happening, without any of your own theories clouding that description, somebody clueful might be able to see just what is the obvious factor you have missed. As things stand, you are just going around in big unproductive circles and giving the rest of us no useful information to help you with. None of the above is intended as a flame, but it's really time to take stock and make a serious attempt to provide all the data so that those who can help are able to understand the problem. Thank you for your tolerance. I'm afraid - to my great embarrassment, that a 5:30am - 3:30am day ultimately results in NON productivity; in spite of my instance to close this issue before calling it a day. In short; Indeed. Your analysis is quite accurate. I'm afraid, after spending s-o-o-o much time on the issue, I became /quite/ obsessed with closure that I made a fool of myself here. Please accept my apologies. In the future, I'll choose a tall Tequila tonic, and a good nights sleep - over spamming the list. :) In short; the title /should/ have read 127.0.0.1/8 In my case; I was working with 2 of my servers - a RELENG_6, and an 7-RC3. The RELENG_6 defaulted to 127.0.0.1/8 While the 7-RC3 defaulted to 127.0.0.1/32 There were other peculiarities which I added to the thread that I thought worth mentioning. But ultimately, only served to cloud the whole matter. Thanks again. --Chris H I hope Greg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Usb problems on 7.0 RELEASE
Earlier I reported usb problems on this list. Since then I have recompiled the kernel and world three times, each time including the latest changes in src. # uname -a FreeBSD hostname.utdallas.edu 7.0-RELEASE FreeBSD 7.0-RELEASE #3: Tue Mar 4 15:19:51 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Today I discovered something interesting. The /etc/devd.conf file was missing a double quote on line 103 and exiting without an error. Once I fixed that, I was able to get sysmouse to work in X for the first time (instead of having to enable moused in /etc/rc.conf). The other problem I've been having is that, if a umass device is connected during boot, the system simply freezes. After boot, I can attach the devices fine. After fixing the problem in devd.conf, I got error messages for the first time during the boot sequence. umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, TIMEOUT umass0: BBB bulk-out clear stall failed, TIMEOUT If I disconnect the device and reboot, the system comes up normally. Then I can connect the devices and (for the first time) see messages in /var/log/messages and on the console showing the devices attaching and detaching. So, obviously the devd.conf problem was causing some of the problems, but I'm still having the problem with attached umass devices during boot. (Even a thumb drive will cause the problem.) Here's my dmesg.boot: # cat /var/run/dmesg.boot Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #3: Tue Mar 4 15:19:51 CST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6700 @ 2.66GHz (2660.01-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 4 real memory = 3487559680 (3325 MB) avail memory = 3408371712 (3250 MB) ACPI APIC Table: DELL B9K FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Mar 4 2008 15:19:40) acpi0: DELL B9K on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 cpu2: ACPI CPU on acpi0 est2: Enhanced SpeedStep Frequency Control on cpu2 p4tcc2: CPU Frequency Thermal Control on cpu2 cpu3: ACPI CPU on acpi0 est3: Enhanced SpeedStep Frequency Control on cpu3 p4tcc3: CPU Frequency Thermal Control on cpu3 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xdc00-0xdcff mem 0xd000-0xdfff,0xfe9f-0xfe9f irq 16 at device 0.0 on pci1 pci0: simple comms at device 3.0 (no driver attached) atapci0: Intel ATA controller port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] pci0: simple comms, UART at device 3.3 (no driver attached) em0: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port 0xecc0-0xecdf mem 0xfebe-0xfebf,0xfebdb000-0xfebdbfff irq 21 at device 25.0 on pci0 em0: Using MSI interrupt em0: Ethernet address: 00:1e:4f:f3:75:95 em0: [FILTER] uhci0: UHCI (generic) USB controller port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0xff00-0xff1f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1:
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=8049UP,LOOPBACK,RUNNING,MULTICAST 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: Usb problems on 7.0 RELEASE
On Tue, Mar 04, 2008 at 09:16:25PM -0600, Paul Schmehl wrote: Earlier I reported usb problems on this list. Since then I have recompiled the kernel and world three times, each time including the latest changes in src. Just to humour me, can you try using a UP kernel and see if the problem still occurs. I have bumped into problems with umass on my son's SMP laptop which don't show up on my UP laptop. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpvGrn1lIHR3.pgp Description: PGP signature
