Re: accepting rtadv broken on 9-STABLE, re driver?
On Sat, 07 Jan 2012 14:23:46 -0600, Hiroki Sato h...@freebsd.org wrote: It is an unexpected behavior and the flag should be set on all interfaces. Can you send me your /etc/rc.conf, /etc/sysctl.conf, and the result of ifconfig -a? Back at work so I have access to the machine again: rc.conf: hostname=tech304.office.xxx.net ifconfig_re0=inet 192.168.93.23/24 defaultrouter=192.168.93.1 ipv6_activate_all_interfaces=YES ipv6_ifconfig_re0=inet6 accept_rtadv sshd_enable=YES linux_enable=YES ntpd_enable=YES ntpdate_enable=YES vboxnet_enable=YES tcp_drop_synfin=YES icmp_log_redirect=YES update_motd=NO dbus_enable=YES hald_enable=YES moused_enable=NO moused_nondefault_enable=NO oss_enable=NO #nginx nginx_enable=YES fcgiwrap_enable=YES fcgiwrap_user=www samba_enable=YES #samba_config=/usr/local/etc/samba34/smb.conf lpd_enable=YES #slim_enable=YES exim_enable=YES sendmail_enable=NONE nfs_client_enable=YES smartd_enable=YES zfs_enable=YES sysctl.conf: # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 net.inet.tcp.drop_synfin=1 net.inet.icmp.log_redirect=1 vfs.usermount=1 net.inet6.ip6.accept_rtadv=1 # ifconfig -a 11:43:29 tech304:~ ifconfig -a re0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether d0:67:e5:17:e1:32 inet6 fe80::d267:e5ff:fe17:e132%re0 prefixlen 64 scopeid 0x2 inet 192.168.93.23 netmask 0xff00 broadcast 192.168.93.255 inet6 2607:f4e0:100:104:d267:e5ff:fe17:e132 prefixlen 64 autoconf nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL vboxnet0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 0a:00:27:00:00:00 nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL Regards, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
building on FreeBSD 7.3 with Clang
Hi. I am trying to build a userspace application on FreeBSD 7.3 with Clang. I have come across 2 problems so far and I am looking for any tips or guidance the community has. My problems are both related to binutils so far: 1. Missing symbols : http://llvm.org/bugs/show_bug.cgi?id=9758 2. crtendS.o problem : http://sourceware.org/bugzilla/show_bug.cgi?id=12887 At this point I need to rebuild my toolchain to get a new crtendS.o. Are there other pitfalls I need to be aware of? Thanks, -Lenny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: accepting rtadv broken on 9-STABLE, re driver?
Mark Felder f...@feld.me wrote in op.v7tvkbkr34t2sn@tech304: fe On Sat, 07 Jan 2012 14:23:46 -0600, Hiroki Sato h...@freebsd.org fe wrote: fe fe It is an unexpected behavior and the flag should be set on all fe interfaces. Can you send me your /etc/rc.conf, /etc/sysctl.conf, and fe the result of ifconfig -a? fe fe Back at work so I have access to the machine again: (snip) fe # ifconfig -a fe fe 11:43:29 tech304:~ ifconfig -a fe re0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric fe 0 mtu 1500 fe options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC fe ether d0:67:e5:17:e1:32 fe inet6 fe80::d267:e5ff:fe17:e132%re0 prefixlen 64 scopeid 0x2 fe inet 192.168.93.23 netmask 0xff00 broadcast 192.168.93.255 fe inet6 2607:f4e0:100:104:d267:e5ff:fe17:e132 prefixlen 64 autoconf fe nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL fe media: Ethernet autoselect (100baseTX full-duplex) fe status: active re0 seems to have ACCEPT_RTADV. What is the problem? fe lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 fe options=3RXCSUM,TXCSUM fe inet6 ::1 prefixlen 128 fe inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 fe inet 127.0.0.1 netmask 0xff00 fe nd6 options=21PERFORMNUD,AUTO_LINKLOCAL fe vboxnet0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 fe ether 0a:00:27:00:00:00 fe nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL -- Hiroki pgpbpIcH7lXYo.pgp Description: PGP signature
Re: accepting rtadv broken on 9-STABLE, re driver?
On Mon, 09 Jan 2012 13:02:24 -0600, Hiroki Sato h...@freebsd.org wrote: re0 seems to have ACCEPT_RTADV. What is the problem? That's because I haven't rebooted Let's start fresh. The normal ipv6 configuration anyone would use: -ipv6_activate_all_interfaces=YES in rc.conf -NO mention of net.inet6.ip6.accept_rtadv in sysctl.conf I boot up, re0 *does not* have ACCEPT_RTADV. I try forcing via the sysctl: net.inet6.ip6.accept_rtadv=1 Still doesn't work! I finally have to result to: ifconfig re0 inet6 accept_rtadv Why? What makes this machine different? All the other machines I run do not require this to get ACCEPT_RTADV. Is it the re driver? My other machines have em and ath interfaces. Thanks, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: trouble with atrtc
On Thu, 2012-01-05 at 10:33 -0500, John Baldwin wrote:
On Wednesday, January 04, 2012 5:22:29 pm Ian Lepore wrote:
[...]
Because atrtc.c has a long and rich history of modifcations, some of
them fairly recent, I thought it would be a good idea to toss out my
ideas for changes here and solicit feedback up front, rather than just
blindly posting a PR with a patch...
It turns out to be very easy to probe for the latched-read behavior with
just a few lines of code in atrtc_start(), so I'd propose doing that and
setting a flag that the in/out code can use to disable the caching of
the current register number on hardware that needs it.
I'd like to add a new public function, atrtc_nmi_enable(int enable) that
drivers can use to manipulate the NMI flag safely under clock_lock and
playing nicely with the register number caching code.
Completely unrelated but nice to have: I'd like to add a tuneable to
control the use of inb(0x84) ops to insert delays after writing to 0x70
and 0x71. Modern hardware doesn't need this, so I think it should
default to not inserting delays.
I've done all these things in our local 8.2 code base and tested them on
all the hardware I've got on hand. If these changes sound acceptable
I'll prepare patches to -current as well.
These changes all sound good to me.
Here is the patch for -current and 9. I can provide a patch to 8-stable
as well; it's essentially the same patch with small context differences.
I've tested this using -current on several systems, recent and old
hardware, including manually bumping up the quality score for the rtc
event timer to force it to get used, and it seems to work without
trouble (and of course I've been testing the same patch in 8.2 for a
while on a bunch of different hardware).
Index: sys/isa/rtc.h
===
RCS file: /local/base/FreeBSD-CVS/src/sys/isa/rtc.h,v
retrieving revision 1.16.2.1
diff -u -p -r1.16.2.1 rtc.h
--- sys/isa/rtc.h 23 Sep 2011 00:51:37 - 1.16.2.1
+++ sys/isa/rtc.h 9 Jan 2012 22:04:12 -
@@ -117,6 +117,7 @@ extern int atrtcclock_disable;
intrtcin(int reg);
void atrtc_restore(void);
void writertc(int reg, u_char val);
+void atrtc_nmi_enable(int enable);
#endif
#endif /* _I386_ISA_RTC_H_ */
Index: sys/x86/isa/atrtc.c
===
RCS file: /local/base/FreeBSD-CVS/src/sys/x86/isa/atrtc.c,v
retrieving revision 1.13.2.1
diff -u -p -r1.13.2.1 atrtc.c
--- sys/x86/isa/atrtc.c 23 Sep 2011 00:51:37 - 1.13.2.1
+++ sys/x86/isa/atrtc.c 9 Jan 2012 22:04:12 -
@@ -55,28 +55,59 @@ __FBSDID($FreeBSD: src/sys/x86/isa/atrt
#defineRTC_LOCKmtx_lock_spin(clock_lock)
#defineRTC_UNLOCK mtx_unlock_spin(clock_lock)
+/* atrtcclock_disable is set to 1 by apm_attach() or by hint.atrtc.0.clock=0 */
intatrtcclock_disable = 0;
-static int rtc_reg = -1;
-static u_char rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF;
-static u_char rtc_statusb = RTCSB_24HR;
+static int use_iodelay = 0; /* set from hint.atrtc.0.use_iodelay */
+
+#define RTC_REINDEX_REQUIRED 0xffU
+#define NMI_ENABLE_BIT0x80U
+
+static u_char nmi_enable;
+static u_char rtc_reg = RTC_REINDEX_REQUIRED;
+static u_char rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF;
+static u_char rtc_statusb = RTCSB_24HR;
+
+/*
+ * Delay after writing to IO_RTC[+1] registers. Modern hardware doesn't
+ * require this expensive delay, so it's a tuneable that's disabled by default.
+ */
+static __inline void
+rtc_iodelay(void)
+{
+ if (use_iodelay)
+ inb(0x84);
+}
/*
* RTC support routines
+ *
+ * Most rtc chipsets let you write a value into the index register and then
each
+ * read of the IO register obtains a new value from the indexed location.
Others
+ * behave as if they latch the indexed value when you write to the index, and
+ * repeated reads keep returning the same value until you write to the index
+ * register again. atrtc_start() probes for this behavior and leaves rtc_reg
+ * set to RTC_REINDEX_REQUIRED if reads keep returning the same value.
*/
+static __inline void
+rtcindex(u_char reg)
+{
+ if (rtc_reg != reg) {
+ if (rtc_reg != RTC_REINDEX_REQUIRED)
+ rtc_reg = reg;
+ outb(IO_RTC, reg | nmi_enable);
+ rtc_iodelay();
+ }
+}
+
int
rtcin(int reg)
{
u_char val;
RTC_LOCK;
- if (rtc_reg != reg) {
- inb(0x84);
- outb(IO_RTC, reg);
- rtc_reg = reg;
- inb(0x84);
- }
+ rtcindex(reg);
val = inb(IO_RTC + 1);
RTC_UNLOCK;
return (val);
@@ -87,14 +118,9 @@ writertc(int reg, u_char val)
{
RTC_LOCK;
- if (rtc_reg != reg) {
- inb(0x84);
- outb(IO_RTC, reg);
- rtc_reg =
Re: accepting rtadv broken on 9-STABLE, re driver?
Mark Felder f...@feld.me wrote in op.v7t4xpuh34t2sn@tech304: fe On Mon, 09 Jan 2012 13:02:24 -0600, Hiroki Sato h...@freebsd.org fe wrote: fe fe re0 seems to have ACCEPT_RTADV. What is the problem? fe fe That's because I haven't rebooted fe fe Let's start fresh. fe fe The normal ipv6 configuration anyone would use: fe fe -ipv6_activate_all_interfaces=YES in rc.conf fe fe -NO mention of net.inet6.ip6.accept_rtadv in sysctl.conf fe fe I boot up, re0 *does not* have ACCEPT_RTADV. This is an expected behavior. ACCEPT_RTADV is disabled by default on 9.X. fe I try forcing via the sysctl: net.inet6.ip6.accept_rtadv=1 fe fe Still doesn't work! This needs a reboot. Did you reboot the box? fe Why? What makes this machine different? All the other machines I run fe do not require this to get ACCEPT_RTADV. Is it the re driver? My other fe machines have em and ath interfaces. Putting the following line net.inet6.ip6.accept_rtadv=1 into /etc/sysctl.conf, and then removing the following line ipv6_ifconfig_re0=inet6 accept_rtadv should work, I think. (Of course a reboot is needed after that). -- Hiroki pgpEXn0yC1Kgo.pgp Description: PGP signature
Re: accepting rtadv broken on 9-STABLE, re driver?
On Mon, 09 Jan 2012 19:56:47 -0600, Hiroki Sato h...@freebsd.org wrote: This is an expected behavior. ACCEPT_RTADV is disabled by default on 9.X. Thanks for clarifying. I'll make sure I update our documentation at work regarding how exactly to get ACCEPT_RTADV working so this is clarified. Regards, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
backup BIOS settings
Hi, Is it possible to backup BIOS settings (CMOS configuration) to file and restore this settings on the other machine (the same hardware configuration and the same BIOS)? I try do it for this way: kldload nvram dd if=/dev/nvram of=nvram.bin (backup) dd if=nvram.bin of=/dev/nvram (restore) but this way always load default BIOS settings, not my (probably there is some kind of error). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: backup BIOS settings
On Tue, 2012-01-10 at 04:01 +0100, Łukasz Kurek wrote: Hi, Is it possible to backup BIOS settings (CMOS configuration) to file and restore this settings on the other machine (the same hardware configuration and the same BIOS)? I try do it for this way: kldload nvram dd if=/dev/nvram of=nvram.bin (backup) dd if=nvram.bin of=/dev/nvram (restore) but this way always load default BIOS settings, not my (probably there is some kind of error). Examine the contents of the nvram.bin file with hexdump. If every byte has the same value, I just posted a patch to this list earlier today (subject is trouble with atrtc) that will fix the problem. Many new RTC chipsets have more than the original 114 bytes of nvram. The nvram driver doesn't currently provide access to the extra banks. I'm not sure whether the BIOS would store anything in those other banks, but if so, failing to save and restore those values might cause the behavior you see. Also, it's not directly related to your question, but I notice the nvram(4) manpage says the driver does nothing about the checksum, but looking at the driver code, it does recalculate the checksum when it writes to nvram. -- Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: backup BIOS settings
On Tue, 2012-01-10 at 04:01 +0100, Łukasz Kurek wrote: Hi, Is it possible to backup BIOS settings (CMOS configuration) to file and restore this settings on the other machine (the same hardware configuration and the same BIOS)? I try do it for this way: kldload nvram dd if=/dev/nvram of=nvram.bin (backup) dd if=nvram.bin of=/dev/nvram (restore) but this way always load default BIOS settings, not my (probably there is some kind of error). Oh wait, the patch I posted can't help, because it fixes a problem that only happens when you read the same location repeatedly, and the nvram driver never does that. But it would still be interesting to examine the nvram.bin file and see if it looks reasonable. -- Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
