Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
On 14.10.2011 02:52, Hiroki Sato wrote: Can you please send me the results of the following commands: Please see the output below each command. I forgot to mention that the ipv6 uplink is a 6to4 tunnel, as you can see below from the 2002: prefix. % ifconfig [tykling@tykburk ~]$ ifconfig re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether 00:24:8c:02:de:01 inet6 fe80::224:8cff:fe02:de01%re0 prefixlen 64 scopeid 0x5 inet6 2002:d947:452:1:224:8cff:fe02:de01 prefixlen 64 autoconf inet 10.10.1.115 netmask 0xff00 broadcast 10.10.1.255 nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active fwe0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 02:1e:8c:b6:37:7b inet6 fe80::1e:8cff:feb6:377b%fwe0 prefixlen 64 scopeid 0x6 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL ch 1 dma 0 fwip0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 lladdr 0.1e.8c.0.1.b6.37.7b.a.2.ff.fe.0.0.0.0 inet6 fe80::21e:8c00:1b6:377b%fwip0 prefixlen 64 scopeid 0x7 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:1b:21:32:fe:80 inet6 fe80::21b:21ff:fe32:fe80%em0 prefixlen 64 scopeid 0xc nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect status: no carrier lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xd inet 127.0.0.1 netmask 0xff00 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL % grep ^ipv6 /etc/rc.conf [tykling@tykburk ~]$ grep ^ipv6 /etc/rc.conf ipv6_activate_all_interfaces=YES % grep ipv6= /etc/rc.conf [tykling@tykburk ~]$ grep ipv6= /etc/rc.conf ifconfig_re0_ipv6=accept_rtadv % ip6addrctl show [tykling@tykburk ~]$ ip6addrctl show Prefix Prec Label Use ::1/128 50 00 ::/0 40 1 2266 2002::/16 30 2 1164 ::/96 20 30 :::0.0.0.0/96 10 40 # /bin/sh -x /etc/rc.d/ip6addrctl start [tykling@tykburk ~]$ sudo /bin/sh -x /etc/rc.d/ip6addrctl start + . /etc/rc.subr + : 'rc.conf(5)' + : 47981 + export RC_PID + [ -z '' ] + _rc_subr_loaded=YES + SYSCTL=/sbin/sysctl + SYSCTL_N='/sbin/sysctl -n' + SYSCTL_W=/sbin/sysctl + ID=/usr/bin/id + IDCMD='if [ -x /usr/bin/id ]; then /usr/bin/id -un; fi' + PS='/bin/ps -ww' + /bin/ps -ww -p 47981 -o jid= + JID=' 0' + _rc_subr_loaded=: + . /etc/network.subr + name=ip6addrctl + set_rcvar + echo ip6addrctl_enable + rcvar=ip6addrctl_enable + start_cmd=ip6addrctl_start + stop_cmd=ip6addrctl_stop + extra_commands='status prefer_ipv6 prefer_ipv4' + status_cmd=ip6addrctl + prefer_ipv6_cmd=ip6addrctl_prefer_ipv6 + prefer_ipv4_cmd=ip6addrctl_prefer_ipv4 + config_file=/etc/ip6addrctl.conf + set_rcvar_obsolete ipv6_enable ipv6_activate_all_interfaces + local _var + _var=ipv6_enable + debug 'rcvar_obsolete: $ipv6_enable(old) - $ipv6_activate_all_interfaces(new) is defined' + rcvars_obsolete=' ipv6_enable' + eval 'ipv6_enable_newvar=ipv6_activate_all_interfaces' + ipv6_enable_newvar=ipv6_activate_all_interfaces + shift 2 + eval 'ipv6_enable_obsolete_msg=' + ipv6_enable_obsolete_msg='' + set_rcvar_obsolete ipv6_prefer ip6addrctl_policy + local _var + _var=ipv6_prefer + debug 'rcvar_obsolete: $ipv6_prefer(old) - $ip6addrctl_policy(new) is defined' + rcvars_obsolete='ipv6_enable ipv6_prefer' + eval 'ipv6_prefer_newvar=ip6addrctl_policy' + ipv6_prefer_newvar=ip6addrctl_policy + shift 2 + eval 'ipv6_prefer_obsolete_msg=' + ipv6_prefer_obsolete_msg='' + load_rc_config ip6addrctl + local _name _var _defval _v _msg _new + _name=ip6addrctl + [ -z ip6addrctl ] + false + [ -r /etc/defaults/rc.conf ] + debug 'Sourcing /etc/defaults/rc.conf' + . /etc/defaults/rc.conf + rc_debug=NO + rc_info=NO + rc_startmsgs=YES + rcshutdown_timeout=30 + early_late_divider=FILESYSTEMS + swapfile=NO + apm_enable=NO + apmd_enable=NO + apmd_flags='' + ddb_enable=NO + ddb_config=/etc/ddb.conf + devd_enable=YES + devd_flags='' + kldxref_enable=NO + kldxref_clobber=NO + kldxref_module_path='' + powerd_enable=NO + powerd_flags='' + tmpmfs=AUTO + tmpsize=20m + tmpmfs_flags=-S + varmfs=AUTO + varsize=32m + varmfs_flags=-S + populate_var=AUTO + cleanvar_enable=YES + local_startup=/usr/local/etc/rc.d + script_name_sep=' ' + rc_conf_files='/etc/rc.conf /etc/rc.conf.local' + zfs_enable=NO + gptboot_enable=YES + gbde_autoattach_all=NO + gbde_devices=NO + gbde_attach_attempts=3 + gbde_lockdir=/etc + geli_devices='' + geli_tries='' +
Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
Thomas Steen Rasmussen tho...@gibfest.dk wrote in 4e97cffc.5020...@gibfest.dk: th On 14.10.2011 02:52, Hiroki Sato wrote: th Can you please send me the results of the following commands: th th Please see the output below each command. I forgot to th mention that the ipv6 uplink is a 6to4 tunnel, as you can th see below from the 2002: prefix. Okay, what is the result of the following? % telnet www.freebsd.org 80 /dev/null -- Hiroki pgpooG9YS30qO.pgp Description: PGP signature
Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
On 14.10.2011 08:14, Hiroki Sato wrote: telnet www.freebsd.org 80 /dev/null [tykling@tykburk ~]$ telnet www.freebsd.org 80 /dev/null Trying 69.147.83.34... Connected to red.freebsd.org. Escape character is '^]'. Connection closed by foreign host. /Thomas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Prepend timestamp in msgbuf
On Oct 13, 2011, at 9:40 PM, Arnaud Lacombe wrote: Hi, On Thu, Oct 13, 2011 at 2:00 PM, lacom...@gmail.com wrote: From: Arnaud Lacombe lacom...@gmail.com Hi folks, There is many case recently when I really wished timestamp were present in the post-mortem msgbuf. Such situation could be when userland application segfault potentially triggering a panic/crash, or have information about the time-wise location of a given message (kernel or userland). Attached patch is available in the git repository at: git://github.com/lacombar/freebsd.git master/topic/msgbuf-timestamp Arnaud Lacombe (3): msgbuf(4): convert `msg_needsnl' to a bit flag msgbuf(4): add logic to prepend timestamp on new line msgbuf(4): add a sysctl to toggle timestamp prepend sys/kern/subr_msgbuf.c | 53 --- sys/sys/msgbuf.h |4 ++- 2 files changed, 48 insertions(+), 9 deletions(-) Cool! I've dreamt for something like this for a long time, it can be very useful. Regards, Nikolay ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: possible mountroot regression
on 30/08/2011 13:01 Andriy Gapon said the following:
So, just to re-iterate, I think that this is indeed a regression and the one
that could be particularly unhelpful for a new release - the time when people
are much more likely to end up at the mountroot prompt during an installation
of
a new system or an upgrade.
Marcel,
is there any chance that this regression can be fixed before the release?
If not, then maybe it would be proper to pull the change that introduced it out
of the release branch (r214006) ?
on 29/08/2011 23:19 Andriy Gapon said the following:
on 29/08/2011 19:45 Marcel Moolenaar said the following:
On Aug 29, 2011, at 1:21 AM, Andriy Gapon wrote:
on 27/08/2011 18:16 Marcel Moolenaar said the following:
On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote:
It seems that after the introduction of the mountroot scripting language
a user
now has exactly one chance to try to specify a correct root device at the
mountroot prompt. I am not sure that that is convenient/enough.
This is no different from before.
Are you sure?
I remember trying multiple (incorrect) possibilities at the prompt and not
getting the panic. But I know that sometimes I have cases of false
memories,
so _I_ am not sure.
I'm sure now that we're both not sure :-)
It's possible the failure mode varied by how the root mount
failed...
Judging from the code before r214006 it shouldn't have panic-ed upon such a
failure:
static int
vfs_mountroot_ask(void)
{
char name[128];
char *mountfrom;
char *options;
for(;;) {
...
gets(name, sizeof(name), 1);
if (name[0] == '\0')
return (1);
if (name[0] == '?') {
printf(\nList of GEOM managed disk devices:\n );
g_dev_print();
continue;
}
if (!vfs_mountroot_try(name, NULL))
return (0);
}
}
So this endless loop was exited only if vfs_mountroot_try() returned
success
(error == 0) or if a user entered an empty string.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
Thomas Steen Rasmussen tho...@gibfest.dk wrote in 4e97d9f3.4020...@gibfest.dk: th On 14.10.2011 08:14, Hiroki Sato wrote: th telnet www.freebsd.org 80 /dev/null th [tykling@tykburk ~]$ telnet www.freebsd.org 80 /dev/null th Trying 69.147.83.34... th Connected to red.freebsd.org. th Escape character is '^]'. th Connection closed by foreign host. Thanks. There is no problem with the source address selection. The last questions are: % route get -inet www.freebsd.org % route get -inet6 www.freebsd.org % netstat -nrf inet6 % ndp -r I guess the second one returns route: writing to routing socket: No such process on your box. Is it correct? -- Hiroki pgpR2d1AI6IIl.pgp Description: PGP signature
Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
On 14-10-2011 10:09, Hiroki Sato wrote: Thanks. There is no problem with the source address selection. The last questions are: % route get -inet www.freebsd.org [tykling@tykburk ~]$ route get -inet www.freebsd.org route to: red.freebsd.org destination: default mask: default gateway: fitfw interface: re0 flags: UP,GATEWAY,DONE,STATIC recvpipe sendpipe ssthresh rtt,msecmtuweightexpire 0 0 0 0 1500 1 0 % route get -inet6 www.freebsd.org [tykling@tykburk ~]$ route get -inet6 www.freebsd.org route to: red.freebsd.org destination: :: mask: default gateway: fe80::20d:f0ff:fe8d:4d23%re0 interface: re0 flags: UP,GATEWAY,DONE recvpipe sendpipe ssthresh rtt,msecmtuweightexpire 0 0 0 0 1500 1 0 % netstat -nrf inet6 [tykling@tykburk ~]$ netstat -nrf inet6 Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRSlo0 = default fe80::20d:f0ff:fe8d:4d23%re0 UG re0 ::1 ::1 UH lo0 :::0.0.0.0/96 ::1 UGRSlo0 2002:d947:452:1::/64 link#5 U re0 2002:d947:452:1:224:8cff:fe02:de01 link#5 UHS lo0 fe80::/10 ::1 UGRSlo0 fe80::%re0/64 link#5 U re0 fe80::224:8cff:fe02:de01%re0 link#5 UHS lo0 fe80::%fwe0/64link#6 U fwe0 fe80::1e:8cff:feb6:377b%fwe0 link#6 UHS lo0 fe80::%fwip0/64 link#7 U fwip0 fe80::21e:8c00:1b6:377b%fwip0 link#7 UHS lo0 fe80::%em0/64 link#12 U em0 fe80::21b:21ff:fe32:fe80%em0 link#12 UHS lo0 fe80::%lo0/64 link#13 U lo0 ff01::%re0/32 fe80::224:8cff:fe02:de01%re0 U re0 ff01::%fwe0/32fe80::1e:8cff:feb6:377b%fwe0 U fwe0 ff01::%fwip0/32 fe80::21e:8c00:1b6:377b%fwip0 U fwip0 ff01::%em0/32 fe80::21b:21ff:fe32:fe80%em0 U em0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRSlo0 ff02::%re0/32 fe80::224:8cff:fe02:de01%re0 U re0 ff02::%fwe0/32fe80::1e:8cff:feb6:377b%fwe0 U fwe0 ff02::%fwip0/32 fe80::21e:8c00:1b6:377b%fwip0 U fwip0 ff02::%em0/32 fe80::21b:21ff:fe32:fe80%em0 U em0 ff02::%lo0/32 ::1 U lo0 % ndp -r [tykling@tykburk ~]$ ndp -r fe80::20d:f0ff:fe8d:4d23%re0 if=re0, flags=, pref=medium, expire=28m15s I guess the second one returns route: writing to routing socket: No such process on your box. Is it correct? No, it returns the route to red.freebsd.org / 2001:4f8:fff6::22 (which is the default route of course). Extra info: [tykling@tykburk ~]$ telnet -6 www.freebsd.org 80 /dev/null Trying 2001:4f8:fff6::22... Connected to red.freebsd.org. Escape character is '^]'. Connection closed by foreign host. Thanks, Thomas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Prepend timestamp in msgbuf
On Fri Oct 14 11, Nikolay Denev wrote: On Oct 13, 2011, at 9:40 PM, Arnaud Lacombe wrote: Hi, On Thu, Oct 13, 2011 at 2:00 PM, lacom...@gmail.com wrote: From: Arnaud Lacombe lacom...@gmail.com Hi folks, There is many case recently when I really wished timestamp were present in the post-mortem msgbuf. Such situation could be when userland application segfault potentially triggering a panic/crash, or have information about the time-wise location of a given message (kernel or userland). Attached patch is available in the git repository at: git://github.com/lacombar/freebsd.git master/topic/msgbuf-timestamp Arnaud Lacombe (3): msgbuf(4): convert `msg_needsnl' to a bit flag msgbuf(4): add logic to prepend timestamp on new line msgbuf(4): add a sysctl to toggle timestamp prepend sys/kern/subr_msgbuf.c | 53 --- sys/sys/msgbuf.h |4 ++- 2 files changed, 48 insertions(+), 9 deletions(-) Cool! I've dreamt for something like this for a long time, it can be very useful. great work! a have a few comments however: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? 2) my dmesg output contains a lot of these entries: 118 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? 4) maybe a new dmesg flag would be a good idea to suppress timestamps. cheers. alex Regards, Nikolay ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Prepend timestamp in msgbuf
In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Prepend timestamp in msgbuf
On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. cheers. alex -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Prepend timestamp in msgbuf
On Fri Oct 14 11, Alexander Best wrote: On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. maybe the granularity of the timestamps could be limited to a static value? the following output doesn't really look pretty: [7.729516] 118/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 blocks, 0.7% fragmentation) [7.891512] 118Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. [8.33519] . [9.440514] 118Setting hostname: otaku. [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 [9.850516] 118Starting wpa_supplicant. [10.335514] 118Starting Network: lo0 ath0. so it would be nice, if trailing zeros got printed out, too. cheers. alex cheers. alex -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Prepend timestamp in msgbuf
On Fri Oct 14 11, Alexander Best wrote: On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. or even better: if timestamp == 1.0 then simply don't ouput it at all. cheers. alex -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: incorrect use of pidfile(3)
On Thu, Oct 13, 2011 at 04:11:40PM +0200, Dag-Erling Smørgrav wrote: Pawel Jakub Dawidek p...@freebsd.org writes: I'm still in opinion that EWOULDBLOCK and EAGAIN (which is the same value on FreeBSD) should be converted to EEXIST on pidfile_open() return. The historical (and documented) behavior is to return EAGAIN. We don't want to duplicate the code of handling EAGAIN into every single pidfile(3) consumer. This is why we hav pidfile(3) API in the first place - to make it easy for people to use. Also if we now have for loop, why not to put count in there? Because if we do, there will be a nanosleep after the last pidfile_read() attempt. We need to break the loop after pidfile_read() failed but before nanosleep(). Right, ok. I'm not very happy about touching pidptr in case of error other than EEXIST. This is not documented, but a bit unexpected anyway. Well, it was your idea, I just moved it to before the loop :) In my patch *pidptr was set to -1 only in the case of EAGAIN from pidfile_read(), not for every other error. BTW. With your patch we will continue even when flopen(3) failed for other reasons, instead of returning NULL. Checking for fd being -1 should not be done in the same statement with other checks. After proposed changes it would look like this, what do you think? http://people.freebsd.org/~pjd/patches/pidfile.3.patch -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpNGouMOHFTt.pgp Description: PGP signature
Re: PANIC: ffs_valloc: dup alloc on boot
That's ok, a more aggressive fsck-from-a-rescue-disk strategy managed to clean things up. J Anderson On 6 October 2011 15:58, Benjamin Kaduk ka...@mit.edu wrote: On Thu, 6 Oct 2011, Jonathan Anderson wrote: On 5 October 2011 23:50, Jonathan Anderson jonat...@freebsd.org wrote: I was about to upgrade my build VM from BETA2 to BETA3, but I can't seem to boot BETA2 any more: I get a ffs_valloc: dup alloc panic on boot, every time. fsck runs and says, ok, I've cleaned things up for you, but then later on, when trying to update motd, FFS dies. Here are two screenshots: fsck succeeding and the relevant backtrace. Mailman seems to have stripped them. -Ben Kaduk -- Jonathan Anderson jonat...@freebsd.org http://freebsd.org/~jonathan/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: On 10/12/2011 08:20, Michael Butler wrote: SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: Intel ICH10DO watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Yes, it can only fix it if the BIOS decides to list it as a system resource in ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as a workaround for lying BIOSes yes? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: incorrect use of pidfile(3)
Pawel Jakub Dawidek p...@freebsd.org writes: After proposed changes it would look like this, what do you think? http://people.freebsd.org/~pjd/patches/pidfile.3.patch Looks OK to me, but you should also remove the paragraph about EAGAIN in the man page. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Prepend timestamp in msgbuf
Alexander Best arun...@freebsd.org writes: On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. maybe the granularity of the timestamps could be limited to a static value? the following output doesn't really look pretty: [7.729516] 118/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 blocks, 0.7% fragmentation) [7.891512] 118Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. [8.33519] . [9.440514] 118Setting hostname: otaku. [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 [9.850516] 118Starting wpa_supplicant. [10.335514] 118Starting Network: lo0 ath0. so it would be nice, if trailing zeros got printed out, too. Why not make formatting similar to linux/xorg logs, e.g. [31.897] (**) Option XkbLayout us [31.897] (II) XINPUT: Adding extended input device default keyboard (type: KEYBOARD, id 7) [ 11485.404] (II) 3rd Button detected: disabling emulate3Button [0.00] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 [0.00] Command line: root=/dev/disk/by-uuid/625db1f5-9b51-4d2d-acb7-6726f4d7e199 ro [...] [ 15.096862] NET: Registered protocol family 10 [ 16.792594] [drm] nouveau :01:00.0: plugged DVI-I-2 [ 26.054186] eth0: no IPv6 routers present A way to convert those timestamps to localtime or time delta[1] post-mortem via dmesg(8) would be good, too. [1] like in tcpdump -ttt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: possible mountroot regression
On Oct 14, 2011, at 12:51 AM, Andriy Gapon wrote: on 30/08/2011 13:01 Andriy Gapon said the following: So, just to re-iterate, I think that this is indeed a regression and the one that could be particularly unhelpful for a new release - the time when people are much more likely to end up at the mountroot prompt during an installation of a new system or an upgrade. Marcel, is there any chance that this regression can be fixed before the release? Probably, yes. How do you want to fix this? You haven't really expressed what you would like to see, other than mentioning that you think it's a regression from before. Arguably, the previous behaviour had a lot to be desired for so since you're worried about the user experience, thinking this through is important. If not, then maybe it would be proper to pull the change that introduced it out of the release branch (r214006) ? Don't be ridiculous. -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: possible mountroot regression
on 14/10/2011 16:37 Marcel Moolenaar said the following: On Oct 14, 2011, at 12:51 AM, Andriy Gapon wrote: on 30/08/2011 13:01 Andriy Gapon said the following: So, just to re-iterate, I think that this is indeed a regression and the one that could be particularly unhelpful for a new release - the time when people are much more likely to end up at the mountroot prompt during an installation of a new system or an upgrade. Marcel, is there any chance that this regression can be fixed before the release? Probably, yes. How do you want to fix this? Simple: revert to the previous behavior. If a user enters incorrect device name (i.e. root mounting fails), then return back to the prompt instead of panicing. You haven't really expressed what you would like to see, other than mentioning that you think it's a regression from before. I thought that what I wrote above was kind of obvious. Arguably, the previous behaviour had a lot to be desired for so since you're worried about the user experience, thinking this through is important. I didn't see anything bad with the previous behavior in this respect. If not, then maybe it would be proper to pull the change that introduced it out of the release branch (r214006) ? Don't be ridiculous. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
x.0 RELASE isn't for production.
That's what most people think. Hi! I would like to say that most freebsd users don't try CURRENT, but try BETAs-x, RCs-x. Why? Because most users don't like compile new kernel and world. It's tediously. You need to download a CURRENT snapshot iso, to install, csup, and then to build kernel and world. FreeBSD project builds CURRENT snapshot every month, but not always. And this volatility is bad. Month is a big period. Very big, imo. For example, 10 day period would be great! And when BETA/RC time comes users rush like mad to test it. And they find errors and bugs. Writing PR, emails and even !pathes! But the lion's share of these pathes doesn't get into the coming BETA or RC. Maintainers say I don't have time [to test it] or It's too late. Why is it late? I'm talking about only BUGS (PRs with pathes), not new features. Let's users test it! In coming BETA/RC. Where are we in a hurry? The BETAs and RCs exists for finding BUGS in coming RELEASE! It's the only purpose of it. Of cause pathes would be commited after x.0 RELEASE to x.1 STABLE. Because of this situation most people says x.0 RELASE isn't for production. All the above applies only to the opening of a new STABLE branch, 9 for this time. I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be longer. Six months, for example. New STABLE branch is very important! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: possible mountroot regression
Andry Gapon wrote:
Simple: revert to the previous behavior. If a user enters incorrect device
name
(i.e. root mounting fails), then return back to the prompt instead of panicing.
That should do the job.
- Arnaud
---
sys/kern/vfs_mountroot.c | 45 +++--
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c
index ccbcb33..ae3ffa7 100644
--- a/sys/kern/vfs_mountroot.c
+++ b/sys/kern/vfs_mountroot.c
@@ -481,28 +481,29 @@ parse_dir_ask(char **conf)
printf(\n);
printf( ? List valid disk boot devices\n);
printf( . Yield 1 second (for background tasks)\n);
- printf( empty lineAbort manual input\n);
+ printf( x Abort manual input)\n);
+
+ do {
+ error = EINVAL;
+ printf(\nmountroot );
+ gets(name, sizeof(name), GETS_ECHO);
+ if (name[0] == '?') {
+ printf(\nList of GEOM managed disk devices:\n );
+ g_dev_print();
+ continue;
+ }
+ if (name[0] == '.') {
+ pause(rmask, hz);
+ continue;
+ }
+ if (name[0] == 'x' name[1] == '\0')
+ break;
+ mnt = name;
+ error = parse_mount(mnt);
+ if (error 0)
+ printf(Invalid specification.\n);
+ } while (error != 0);
- again:
- printf(\nmountroot );
- gets(name, sizeof(name), GETS_ECHO);
- if (name[0] == '\0')
- return (0);
- if (name[0] == '?') {
- printf(\nList of GEOM managed disk devices:\n );
- g_dev_print();
- goto again;
- }
- if (name[0] == '.') {
- pause(rmask, hz);
- goto again;
- }
- mnt = name;
- error = parse_mount(mnt);
- if (error == -1) {
- printf(Invalid specification.\n);
- goto again;
- }
return (error);
}
--
1.7.6.153.g78432
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: possible mountroot regression
Hi,
On Fri, Oct 14, 2011 at 11:54 AM, Arnaud Lacombe lacom...@gmail.com wrote:
Andry Gapon wrote:
Simple: revert to the previous behavior. If a user enters incorrect device
name
(i.e. root mounting fails), then return back to the prompt instead of
panicing.
That should do the job.
Actually, my primary interest in that patch was to be able to hit
enter to be sure I had the prompt (think a serial console connecting
after the message has been displayed), then enter the information. Not
sure that'd suit what you expect though.
- Arnaud
- Arnaud
---
sys/kern/vfs_mountroot.c | 45 +++--
1 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/sys/kern/vfs_mountroot.c b/sys/kern/vfs_mountroot.c
index ccbcb33..ae3ffa7 100644
--- a/sys/kern/vfs_mountroot.c
+++ b/sys/kern/vfs_mountroot.c
@@ -481,28 +481,29 @@ parse_dir_ask(char **conf)
printf(\n);
printf( ? List valid disk boot devices\n);
printf( . Yield 1 second (for background tasks)\n);
- printf( empty line Abort manual input\n);
+ printf( x Abort manual input)\n);
+
+ do {
+ error = EINVAL;
+ printf(\nmountroot );
+ gets(name, sizeof(name), GETS_ECHO);
+ if (name[0] == '?') {
+ printf(\nList of GEOM managed disk devices:\n );
+ g_dev_print();
+ continue;
+ }
+ if (name[0] == '.') {
+ pause(rmask, hz);
+ continue;
+ }
+ if (name[0] == 'x' name[1] == '\0')
+ break;
+ mnt = name;
+ error = parse_mount(mnt);
+ if (error 0)
+ printf(Invalid specification.\n);
+ } while (error != 0);
- again:
- printf(\nmountroot );
- gets(name, sizeof(name), GETS_ECHO);
- if (name[0] == '\0')
- return (0);
- if (name[0] == '?') {
- printf(\nList of GEOM managed disk devices:\n );
- g_dev_print();
- goto again;
- }
- if (name[0] == '.') {
- pause(rmask, hz);
- goto again;
- }
- mnt = name;
- error = parse_mount(mnt);
- if (error == -1) {
- printf(Invalid specification.\n);
- goto again;
- }
return (error);
}
--
1.7.6.153.g78432
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: x.0 RELASE isn't for production.
On Fri, Oct 14, 2011 at 11:55:28AM +0400, Pavel Timofeev wrote: That's what most people think. Could be. But to the extent that it's true, I have no reason to believe that it's a perspective that is held uniquely (or even principally) about FreeBSD. Hi! I would like to say that most freebsd users don't try CURRENT, but try BETAs-x, RCs-x. Errr... I'll suggest that most folks who posit what most folks do don't actually determine this empirically. Some of them probably engage in something called projection (in lieu of performing appropriate polling, for example). Why? Because most users don't like compile new kernel and world. It's tediously. Errr... So what? Doing it doesn't prevent one from doing other things (within reason), and the process gets done when it's done. And it's the computer doing the tedious stuff -- which is something at which they excel. I'm in the habit of tracking stable/8, stable/9, and head on a daily basis on a personal build machine and on my laptop. I also update all of the installed ports on each machine daily. I don't expect most folks to do that; actually, I don't expect anyone else to do (precisely) that. You need to download a CURRENT snapshot iso, to install, csup, and then to build kernel and world. Really? I don't think I've ever used a snapshot. I do maintain a private mirror of the FreeBSD CVS SVN repositories (and mirror those to my laptop). I find the tracking process fairly straightforward, and only rarely surprising (though usually, if it is surprising, it's not in an especially good way -- but then I'm occasionally able to help at least provide some encouragement to fix the cause of the surprise). FreeBSD project builds CURRENT snapshot every month, but not always. And this volatility is bad. Month is a big period. Very big, imo. For example, 10 day period would be great! If you want finer-grained updates, one way is to use the source. The project still maintains the SVN-to-CVS exporting process, and a network of public CVS mirrors around the planet. The cvs program is in the FreeBSD base system. You have the resources necessary to do this, if you want to do so. And when BETA/RC time comes users rush like mad to test it. And they find errors and bugs. Writing PR, emails and even !pathes! There are certainly some folks whose first exposure to a new release is in the later stages of the release process. Changing parameters (such as the duration of the process) may affect the population distribution some, but it won't change the fact that there are some folks who will not test early enough to raise some valid objections or concerns in sufficient time to have them addressed in a completely satisfactory manner prior to the release. This is something that appears to involve rather deep-sewated aspects of human nature, and it is not in the power of any organization to prevent it. The best anyone (or any gropu) can do is find ways to mitigate it, nad learn to move on. But the lion's share of these pathes doesn't get into the coming BETA or RC. Maintainers say I don't have time [to test it] or It's too late. Given that the process is intended to produce a release, there comes a time when it is necessary to draw the line and cut the release. Software is rarely perfect. I'd venture that software of sufficient complexity is never perfect. I'll also ventire that FreeBSD -- much as I enjoy using and working with it -- is sufficiently complex as to be imperfect. In fact, it is a work in progress. This ought not be either surprising or unfamiliar to anyone who has been on the planet long enough to recognize the parallels with humans -- remarkably few humans are perfect, either, after all. :-} [And yes, I include myself as imperfect -- certainly as long as I'm still breathing.] Why is it late? I'm talking about only BUGS (PRs with pathes), not new features. Let's users test it! In coming BETA/RC. Where are we in a hurry? The BETAs and RCs exists for finding BUGS in coming RELEASE! It's the only purpose of it. Of cause pathes would be commited after x.0 RELEASE to x.1 STABLE. Because of this situation most people says x.0 RELASE isn't for production. Much depends on the workload in question. There are folks who run CURRENT/head in production environments. (I'm not one of them.) I do, however, run stable/8 in a (small) production environment; for that, I update weekly (unless I have some reason to do otherwise). All the above applies only to the opening of a new STABLE branch, 9 for this time. I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be longer. Six months, for example. New STABLE branch is very important! So is opening head up to allow developers to work on and commit new code. As with many things in engineering, there's a cost/benefit trade-off. RE is doing a remarkable job, IMO. Folks who care sufficiently will find ways to test early enough to be useful. Peace, david -- David
Re: [RFC] Prepend timestamp in msgbuf
Hi, On Fri, Oct 14, 2011 at 8:52 AM, Nali Toja nalit...@gmail.com wrote: Alexander Best arun...@freebsd.org writes: On Fri Oct 14 11, Poul-Henning Kamp wrote: In message 20111014085609.ga3...@freebsd.org, Alexander Best writes: 1) would it be possible to prepend those timestamps to the actual console output and not only to the output of demsg? maybe via a sysctl toggle? The kernel does not know enough about timezones to emit anything but UTC timestamps. hmm ok. 2) my dmesg output contains a lot of these entries: 118 These are magic markers for syslogd(8) specifying priority. it would be nice, if their output could be turned off via a dmesg flag imo. 3) roughly the first 30 lines of my dmesg output have the timestamp [1.0]. would it be possible to have more accuracy there? No, because we don't know the time until we've found the RTC chip. maybe prepending the output with [??] instead of [1.0] would make more sense, so users knows that those timestamps are bogus. maybe the granularity of the timestamps could be limited to a static value? the following output doesn't really look pretty: [7.729516] 118/dev/ufs/varfs: clean, 879143 free (7407 frags, 108967 blocks, 0.7% fragmentation) [7.891512] 118Mounting local file systems:WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. [8.33519] . [9.440514] 118Setting hostname: otaku. [9.744516] wlan0: Ethernet address: 00:0f:b5:82:07:c8 [9.850516] 118Starting wpa_supplicant. [10.335514] 118Starting Network: lo0 ath0. so it would be nice, if trailing zeros got printed out, too. Why not make formatting similar to linux/xorg logs, e.g. [ 31.897] (**) Option XkbLayout us [ 31.897] (II) XINPUT: Adding extended input device default keyboard (type: KEYBOARD, id 7) [ 11485.404] (II) 3rd Button detected: disabling emulate3Button [ 0.00] Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 [ 0.00] Command line: root=/dev/disk/by-uuid/625db1f5-9b51-4d2d-acb7-6726f4d7e199 ro [...] [ 15.096862] NET: Registered protocol family 10 [ 16.792594] [drm] nouveau :01:00.0: plugged DVI-I-2 [ 26.054186] eth0: no IPv6 routers present A way to convert those timestamps to localtime or time delta[1] post-mortem via dmesg(8) would be good, too. well, I do not care for the pretty side of the thing, however, this is just a matter length modifier in the string format; should be trivial to fix. - Arnaud [1] like in tcpdump -ttt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: x.0 RELASE isn't for production.
Hi, On Fri, Oct 14, 2011 at 12:05 PM, David Wolfskill da...@catwhisker.org wrote: On Fri, Oct 14, 2011 at 11:55:28AM +0400, Pavel Timofeev wrote: That's what most people think. Could be. But to the extent that it's true, I have no reason to believe that it's a perspective that is held uniquely (or even principally) about FreeBSD. but this is far from being universal statement too, cf the Linux v3.0 release, which was just another regular kernel release. - Arnaud. ps: can you fix you MUA not to add Reply-to: freebsd-current@freebsd.org ? I replied to _you_, David Wolfskill, not an impersonal mailing list. Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/14/11 04:35, John Baldwin wrote: On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: On 10/12/2011 08:20, Michael Butler wrote: SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: Intel ICH10DO watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Yes, it can only fix it if the BIOS decides to list it as a system resource in ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as a workaround for lying BIOSes yes? I do have debug.acpi.disabled=hostres but it doesn't seem help in my case (Dell Latitude D630): ichwd0: Intel ICH8M watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 ichwd0: Intel ICH8M watchdog timer at port 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Is there something I should look at or additional information needed? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOmHLXAAoJEATO+BI/yjfB7V8H+wdhIcXBKAfkyTNnWyj08AzT XkhR5LWbb/G/FF+Lgr9qBh0YGqbWJy7nPISGN38zIxerrt515SWOhP75k9B2kx45 MojrsDqDxxiU8p9JsuTayrt4t3mZ+mRIAOTvNLs5TL4Rkmuxr9YgJysHQDvk2OmS bslE1inEJ70tuu/NmvgxlZHgIsjgLTjuOOHxPK2rDznS/JYlp8pDznVl105kQR50 gt4AucI3/ovKGP5uscNLxHRVlau43FWzWTdOcWon183sbmmbwCrI9BmvQDYBaQLU SUT0iWVWC2R3/fVTVJVYjdYdlf9BDuenCK5VqLfLfHE6M2ZIWZvyMIvuqKvB6jE= =ETlJ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
Hi,
On Fri, 14 Oct 2011 17:09:11 +0900 (JST)
Hiroki Sato h...@freebsd.org said:
hrs Thomas Steen Rasmussen tho...@gibfest.dk wrote
hrs in 4e97d9f3.4020...@gibfest.dk:
th On 14.10.2011 08:14, Hiroki Sato wrote:
hrs th telnet www.freebsd.org 80 /dev/null
th [tykling@tykburk ~]$ telnet www.freebsd.org 80 /dev/null
th Trying 69.147.83.34...
th Connected to red.freebsd.org.
th Escape character is '^]'.
th Connection closed by foreign host.
hrs Thanks. There is no problem with the source address selection. The
hrs last questions are:
hrs % route get -inet www.freebsd.org
hrs % route get -inet6 www.freebsd.org
hrs % netstat -nrf inet6
hrs % ndp -r
hrs I guess the second one returns route: writing to routing socket: No
hrs such process on your box. Is it correct?
AFAIK, recent Firefox implements Happy Eyeballs. So, I suspect it
doesn't obey RFC 3484, anymore.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
On 10/14/2011 10:35, Xin LI wrote: On 10/14/11 04:35, John Baldwin wrote: On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: On 10/12/2011 08:20, Michael Butler wrote: SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: Intel ICH10DO watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Yes, it can only fix it if the BIOS decides to list it as a system resource in ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as a workaround for lying BIOSes yes? As I reported previously, that didn't work for me. I'll try it again next time I reboot JIC. FYI, I also have a Dell system, Optiplex 960. I do have debug.acpi.disabled=hostres but it doesn't seem help in my case (Dell Latitude D630): ichwd0: Intel ICH8M watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 ichwd0: Intel ICH8M watchdog timer at port 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Is there something I should look at or additional information needed? Cheers, -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
On Friday, October 14, 2011 1:35:19 pm Xin LI wrote: On 10/14/11 04:35, John Baldwin wrote: On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: On 10/12/2011 08:20, Michael Butler wrote: SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: Intel ICH10DO watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Yes, it can only fix it if the BIOS decides to list it as a system resource in ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as a workaround for lying BIOSes yes? I do have debug.acpi.disabled=hostres but it doesn't seem help in my case (Dell Latitude D630): ichwd0: Intel ICH8M watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 ichwd0: Intel ICH8M watchdog timer at port 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Is there something I should look at or additional information needed? Hmm, is your isab device behind a PCI-PCI bridge? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/14/11 10:58, John Baldwin wrote: On Friday, October 14, 2011 1:35:19 pm Xin LI wrote: On 10/14/11 04:35, John Baldwin wrote: On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: On 10/12/2011 08:20, Michael Butler wrote: SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: Intel ICH10DO watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Yes, it can only fix it if the BIOS decides to list it as a system resource in ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as a workaround for lying BIOSes yes? I do have debug.acpi.disabled=hostres but it doesn't seem help in my case (Dell Latitude D630): ichwd0: Intel ICH8M watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 ichwd0: Intel ICH8M watchdog timer at port 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Is there something I should look at or additional information needed? Hmm, is your isab device behind a PCI-PCI bridge? Looks like it's not: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 [...] isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 [...] ichwd0: Intel ICH8M watchdog timer on isa0 ichwd0: unable to reserve GCS registers nexus0 [...] acpi0 Interrupt request lines: 9 [...] pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci0 hostb0 pnpinfo vendor=0x8086 device=0x2a00 subvendor=0x1028 subdevice=0x01f9 class=0x06 at slot=0 function=0 pcib1 pnpinfo vendor=0x8086 device=0x2a01 subvendor=0x1028 subdevice=0x01f9 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.AGP_ I/O ports: 0xe000-0xefff I/O memory addresses: 0xe000-0xefff 0xf200-0xf6ef pci1 vgapci0 pnpinfo vendor=0x10de device=0x042b subvendor=0x1028 subdevice=0x01f9 class=0x03 at slot=0 function=0 handle=\_SB_.PCI0.AGP_.VID_ Interrupt request lines: 16 pcib1 I/O port window: 0xef00-0xef7f pcib1 memory window: 0xf200-0xf3ff 0xf500-0xf5ff pcib1 prefetch window: 0xe000-0xefff vgapm0 nvidia0 drm0 Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOmIdjAAoJEATO+BI/yjfBIcUH/jY7XImBpwLLlCxZub6G9rwR DhuxTPdGLF3lZTU1iGD+Ypdn15R1hjdA2FMKu88bFGAkBLWcmcrOThQoPv1f8mXf FOrKw2MMowpv/GO8kuGFADDZCoyXWRfdjIX9NNpTpcVgr/WxgSU+IFafSQpPm/dW nYjNVjCR8gbYvfTd6nHs12WZDFubs3qITOeRwboU51l60QlJgwIDe2FszP19RL7M RuAQZWdK7pqNdjdviGRxf0/IhZFLgrrJwtwAoO2bdMSat+qJan0F0vboR6KHfeTI YTJuw4zKDDuLSgMN7bBSgd+XEk/e28YSwOU6SaEUVWs+SaKTzhQgCeGKTc6YK5Q= =OibA -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 3 show-stopper issues with 9-BETA3
On Wed, 5 Oct 2011, Ian FREISLICH wrote: In no particular order: It's a shame that nobody has yet picked up on this, it is a very useful list of bugs in 9.0. Is there any chance you could log these three issues as three separate PRs so that they don't get lost? Please tag them with [regression] in the subject if they are indeed regressions from a previous version (they sound like they are) so that they hopefully get onto the release engineering radar. 1. bce(4) transmit and recieve ring buffer overruns On a moderately busy router with a full BGP table and aggregate throughput of between 200mbps and 800mbps, I get these buffer overruns at an average rate of 28 per second on the busiest interface. [firewall1.jnb1] ~ # sysctl dev.bce |grep com_no_buffers dev.bce.0.com_no_buffers: 101 dev.bce.1.com_no_buffers: 0 dev.bce.2.com_no_buffers: 32547 dev.bce.3.com_no_buffers: 444 I've tried increasing the TX_PAGES and RX_PAGES in sys/dev/bce/if_bcereg.h as I've done in the past (to 64) which is what resolved this problem on 8.2-STABLE to no avail. It appears that there is a hard limit of 8 according to bce_set_tunables() in if_bce.c. But no values to hw.bce.tx_pages and hw.bce.rx_pages makes the slightest difference. 2. carp(4) on my backup router randomly takes over MASTER on the standby host, but when ifconfig claims the carp interface is master tcpdump shows that it's not broadcasting its advertisement. The actual master still broadcasts and no setting of advskew or advbase changes the 9-BETA host's idea of who is actually master. I have to reboot the host to reset the carp interfaces. destroying and re-creating them just brings them up as backup for about a second and then they regress to master. Is ipv6 involved in this? Do you have a couple of sample config files that I can drop onto two machines and recreate the issue, by any chance? 3. PF doesn't expire state. The state table on my older host (pre OpenBSD-4.5) has the following stats: Status: Enabled for 0 days 00:37:17 Debug: Urgent State Table Total Rate current entries 169546 searches9438745142193.8/s inserts 4012389 1793.6/s removals 3842843 1717.9/s The 9-BETA3 host's current entries exactly match the number of inserts until it hits the hard limit of 1.5M entries and can add no more. It takes about 10 minutes to fill up and then no new flows are routed. I've seen a few reports of this, and it's quite concerning. Please, can you submit this as a PR? Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
On 10/14/2011 12:03, Xin LI wrote: Hmm, is your isab device behind a PCI-PCI bridge? Me either: isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[RFC] FDT fix for 64 bit platforms
I'm planning commit this -CURRENT if there an no objections. In the current implementation, phandle is used to store a pointer to the location inside the device tree. Since phandle_t is u32, this will not work on 64 bit platforms. With this fix, the phandle is the offset from the start of device tree pointer 'fdtp', which will be 32 bit. Review or testing from device tree users will be welcome. JC. fdt-64-fix.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixed: ichwd failure to attach
On Friday, October 14, 2011 3:03:00 pm Xin LI wrote: On 10/14/11 10:58, John Baldwin wrote: On Friday, October 14, 2011 1:35:19 pm Xin LI wrote: On 10/14/11 04:35, John Baldwin wrote: On Thursday, October 13, 2011 6:26:26 pm Doug Barton wrote: On 10/12/2011 08:20, Michael Butler wrote: SVN r226302 solves the ichwd failure to attach issue .. Still failing for me: ichwd0: Intel ICH10DO watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Yes, it can only fix it if the BIOS decides to list it as a system resource in ACPI. However, using 'debug.acpi.disabled=hostres' should still be working as a workaround for lying BIOSes yes? I do have debug.acpi.disabled=hostres but it doesn't seem help in my case (Dell Latitude D630): ichwd0: Intel ICH8M watchdog timer on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 ichwd0: Intel ICH8M watchdog timer at port 0x1030-0x1037,0x1060-0x107f on isa0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Is there something I should look at or additional information needed? Hmm, is your isab device behind a PCI-PCI bridge? Looks like it's not: Hmm, the NEW_PCIB bits only affect two things: 1) Resource allocation for devices behind PCI-PCI bridges, and 2) Resource allocation for devices behind Host-PCI bridges (but debug.acpi.disabled=hostres should turn that off). I'll see if I can't look in my old thread to see why the allocations are failing. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-beta3 preferring ipv4 over ipv6 with ipv6_activate_all_interfaces=YES
On 10/14/2011 10:38, Hajimu UMEMOTO wrote: AFAIK, recent Firefox implements Happy Eyeballs. So, I suspect it doesn't obey RFC 3484, anymore. My understanding is that they added it, then turned it off because it didn't work as expected. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 3 show-stopper issues with 9-BETA3
On 14/10/2011 19:58, Gavin Atkinson wrote: 3. PF doesn't expire state. The state table on my older host (pre OpenBSD-4.5) has the following stats: Status: Enabled for 0 days 00:37:17 Debug: Urgent State Table Total Rate current entries 169546 searches9438745142193.8/s inserts 4012389 1793.6/s removals 3842843 1717.9/s The 9-BETA3 host's current entries exactly match the number of inserts until it hits the hard limit of 1.5M entries and can add no more. It takes about 10 minutes to fill up and then no new flows are routed. I've seen a few reports of this, and it's quite concerning. Please, can you submit this as a PR? For tracking, this was a previous report with apparently a temporary workaround. http://lists.freebsd.org/pipermail/freebsd-pf/2011-October/006333.html I have a stable-9 virtual machine i can test on if needed but I have pf loaded as a module at the moment so dont have the issue. Vince ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] FDT fix for 64 bit platforms
On 10/14/11 14:10, Jayachandran C. wrote: I'm planning commit this -CURRENT if there an no objections. In the current implementation, phandle is used to store a pointer to the location inside the device tree. Since phandle_t is u32, this will not work on 64 bit platforms. With this fix, the phandle is the offset from the start of device tree pointer 'fdtp', which will be 32 bit. Review or testing from device tree users will be welcome. JC. Why not use offsets into the FDT rather than full pointers? I believe having phandles greater than 32 bits violates the FDT spec, and declaring that the FDT can't itself be larger than 4 GB seems reasonable. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: x.0 RELASE isn't for production.
On Fri, Oct 14, 2011 at 10:55 AM, Pavel Timofeev tim...@gmail.com wrote: That's what most people think. I think we hurry. Imo, BETA/RC period for !NEW! STABLE branch should be longer. Six months, for example. New STABLE branch is very important! IMHO different OS releases (Unix or not) are usually at the state of FreeBSD current regarding stability. FreeBSD late BETA and early RC are usually very stable. Therefore the approximate one month period between the first beta and the release is adequate time. Many users are reluctant to follow stable because they have to go through the wolrd kernel procedure. Since freebsd-update exists as a means of binary upgrading a system through releases, I don't think that it would be a bad idea to be able to use is for stable as well. Let's assume that we would have monthly minor releases something like 9.0.1, 9.0.2 etc. That could ease the fear of .0 release. This is coming from someone who is using current all the time for workstations and stable for production servers and never uses freebsd-update! Best Regards -- George Kontostanos aisecure.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
