Re: make tinderbox failures
On Fri, 26 Oct 2012 15:31:50 -0700 m...@freebsd.org wrote: Thanks for fixes! Is the reason the public tinderbox didn't see these because it has explicit lists of arch/CONF kernels to build, while make tinderbox on my machine just builds all the capitalized files as configuration files? I don't know about the MIPS builds but with ARM it is because the tinderbox only builds for TARGET_ARCH=arm. 2 months ago I updated the ARM configs to set their machine option correctly. This meant the kernels sere built with the correct toolchain in make tinderbox but not the public tinderbox. The correct fix is to update the public tinderbox to build arm, armv6 and armeb. Andrew ___ 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: Interfaces connected by bridge(4) do not pass arp replies
Kim, On Mon, Oct 29, 2012 at 05:59:04PM -0400, Kim Culhan wrote: K What svn revision of FreeBSD -current are you running? K K FreeBSD head r238604. K K I should have mentioned earlier this is with r242126, there have been K some changes K to the network code since 238604, maybe that is why you don't have this problem. If you can do binary search, that may be valuable. -- Totus tuus, Glebius. ___ 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: Interfaces connected by bridge(4) do not pass arp replies
On Tue, Oct 30, 2012 at 8:19 AM, Gleb Smirnoff gleb...@freebsd.org wrote: Kim, On Mon, Oct 29, 2012 at 05:59:04PM -0400, Kim Culhan wrote: K What svn revision of FreeBSD -current are you running? K K FreeBSD head r238604. K K I should have mentioned earlier this is with r242126, there have been K some changes K to the network code since 238604, maybe that is why you don't have this problem. If you can do binary search, that may be valuable. -- Totus tuus, Glebius. Ok I can begin that process, Monthadar since you have an earlier version can you try a test: From a machine on one of your 2 interfaces, can you ping a machine on the other interface? Do you see the MAC for a machine on the other interface in the arp table? When this problem is present, it is possible to reach the router and out to the internet (if it is routed that way) but in the case of the wireless interface, for example, you cannot reach a machine on the wired interface. The interfaces here: bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 02:f3:8d:7d:04:00 inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: msk0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 2 priority 128 path cost 55 member: em0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 1 priority 128 path cost 200 member: wlan1 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 11 priority 128 path cost 3 msk0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c0019RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWTSO,LINKSTATE ether 00:1e:8c:0a:50:e2 inet6 fe80::21e:8cff:fe0a:50e2%msk0 prefixlen 64 scopeid 0x2 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:0e:0c:7f:cf:02 inet6 fe80::20e:cff:fe7f:cf02%em0 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active In rc.conf the bridge is created with: ifconfig_bridge0=inet 10.0.0.1 netmask 255.255.255.0 addm wlan1 addm em0 addm msk0 up thanks -kim ___ 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: Interfaces connected by bridge(4) do not pass arp replies
On Tue, Oct 30, 2012 at 9:29 AM, Kim Culhan w8hd...@gmail.com wrote: On Tue, Oct 30, 2012 at 8:19 AM, Gleb Smirnoff gleb...@freebsd.org wrote: Kim, On Mon, Oct 29, 2012 at 05:59:04PM -0400, Kim Culhan wrote: K What svn revision of FreeBSD -current are you running? K K FreeBSD head r238604. K K I should have mentioned earlier this is with r242126, there have been K some changes K to the network code since 238604, maybe that is why you don't have this problem. If you can do binary search, that may be valuable. -- Totus tuus, Glebius. Ok I can begin that process, Monthadar since you have an earlier version can you try a test: From a machine on one of your 2 interfaces, can you ping a machine on the other interface? Do you see the MAC for a machine on the other interface in the arp table? When this problem is present, it is possible to reach the router and out to the internet (if it is routed that way) but in the case of the wireless interface, for example, you cannot reach a machine on the wired interface. The interfaces here: Sorry omitted one interface: wlan1: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 ether fa:d1:11:38:3c:e5 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng hostap status: running ssid ap2 channel 6 (2437 MHz 11g ht/40+) bssid fa:d1:11:38:3c:e5 regdomain 32924 country CN indoor ecm authmode OPEN privacy OFF txpower 20 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8 shortgi wme burst dtimperiod 1 -kim ___ 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: Small Ivy features: FSGSBASE and SMEP.
On Sun, Sep 09, 2012 at 11:29:05PM +0300, Konstantin Belousov wrote: On Sun, Sep 09, 2012 at 02:02:55PM +0300, Konstantin Belousov wrote: On Sun, Sep 09, 2012 at 08:42:37AM +0200, Michael Fuckner wrote: Hi all, I changed your patch slightly to apply to specialreh.h on STABLE root@c64:/root # diff smep.1.patch.bak smep.1.patch 80c80 diff --git a/sys/x86/include/specialreg.h b/sys/x86/include/specialreg.h --- diff --git a/sys/amd64/include/specialreg.h b/sys/amd64/include/specialreg.h 82,83c82,83 --- a/sys/x86/include/specialreg.h +++ b/sys/x86/include/specialreg.h --- --- a/sys/amd64/include/specialreg.h +++ b/sys/amd64/include/specialreg.h I got a new kernel, but it is stuck immediately (kerneltrap 9 with interrupts disabled), system doesn't boot on E3-1230 V2 on Supermicro X9SCM-IIF Anything else I could check? I need the backtrace and the whole kernel messages. At least, there was a typo in the definition of CR4_FSGSBASE. I still need verbose dmesg and panic messages, if any, with the http://people.freebsd.org/~kib/misc/smep.2.patch version of the patch. With a help from Andrey, who has access to the hardware supporting SMEP, I fixed the issue with double-fault on SMEP enable. The issue was due to loader(8) making a handoff to the kernel with 1GB identity mapping which has the PG_U bit set. As a result, after enabling the CR4.SMEP, the #pf was generated immediately. But since the handler, if any, is also mapped with PG_U, double-fault happen and machine was reset. Updated patch, also fixing other minor problems with the features display, is at http://people.freebsd.org/~kib/misc/smep.3.patch . Please test. Regards, Michael! On 09/08/2012 08:10 PM, Konstantin Belousov wrote: Please find at http://people.freebsd.org/~kib/misc/smep.1.patch the patch which should enable the FSGSBASE and SMEP features supposedly present in the IvyBridge CPUs. FSGSBASE are four new instructions available in the 64bit mode only. They allow to access bases for %fs and %gs without touching MSRs. This makes it possible to both read and write bases in the user mode, or in ring 0 with lower overhead. At the moment, WRFSBASE/WRGSBASE instructions should work, but are useless since any interrupt or context switch overrides bases with the values set by the arch syscall. Still, RDFSBASE/RDGSBASE might be useful for some code and I see no reason not to enable them. SMEP is the nice feature of the processor which makes it trap if ring 0 tries to execute an instruction from usermode-accessible page. It is another mitigation for things like calling user-controllable function pointer in kernel, as well as a protection for NULL function pointer dereference. I am sure that we never execute anything in kernel from user page, but I did not tested the patch since I have no Ivy machine. I need your reports about boot on Ivy with patch applied. Please include the lines from verbose dmesg with CPU Features. In particular, the 'Standard Extended Features' report should appear in output. Thanks. pgps4qfF5miZc.pgp Description: PGP signature
Supermicro X8DT6 crashes in bootloader after r239066
I have a X8DT6 that appears to crash in the bootloader from HEAD. I say appears to because it's difficult to really see what the problem is; the system reboots pretty much as soon as it enters the FreeBSD boot process. The problem affects PXE booting, booting from ZFS on GPT on a SATA drive and UFS on MBR on a USB stick. The problem only occurs if I have any SATA disks plugged in. If I remove all SATA disks I can successfully PXE boot or boot from a USB key. I've tried with a couple of different SATA disks, some with GPT and some with MBR, and the reboot happens in both cases. The last things that I see on the serial console before the reboot is: DHCP..- ^[[06;07H^[[06;00HDH CP..\ ^[ [06;07H^[[05;00HCLIENT MAC ADDR: 00 25 90 92 19 94 GUID: 84F7C23B 5F21 2533 625 C 002590921994 ^[[06;00HCLIENT IP: 172.16.1.50 MASK: 255.255.255.0 DHCP IP: 1 72.16.1.1^[[07;00HGATEWAY IP: 172.16.1.1 ^[[08;00HPXE Loader 1.00^[[2JM-^@^[[01;00H^[[0 m^[[2m^[[0m^[[2;30;40m ^@^[[0m^[[2;37;40m ^[[02;00H^[[0m^[[2;30;40m So it really doesn't seem to get very far at all. I've bisected and confirmed that the problem was introduced in r239066. I tried reverting that commit locally and I can boot fine again. I took a quick look at that commit but it appears to be way over my head. I'm willing to test patches or gather more debugging information; this thing isn't going anywhere until I can get it booting. :) Ryan ___ 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: Supermicro X8DT6 crashes in bootloader after r239066
On Tue, Oct 30, 2012 at 08:34:53PM -0400, Ryan Stone wrote:
I have a X8DT6 that appears to crash in the bootloader from HEAD. I say
appears to because it's difficult to really see what the problem is; the
system reboots pretty much as soon as it enters the FreeBSD boot process.
The problem affects PXE booting, booting from ZFS on GPT on a SATA drive
and UFS on MBR on a USB stick.
The problem only occurs if I have any SATA disks plugged in. If I remove
all SATA disks I can successfully PXE boot or boot from a USB key. I've
tried with a couple of different SATA disks, some with GPT and some with
MBR, and the reboot happens in both cases.
The last things that I see on the serial console before the reboot is:
DHCP..-
^[[06;07H^[[06;00HDH
CP..\
^[
[06;07H^[[05;00HCLIENT MAC ADDR: 00 25 90 92 19 94 GUID: 84F7C23B 5F21
2533 625
C 002590921994 ^[[06;00HCLIENT IP: 172.16.1.50 MASK: 255.255.255.0 DHCP
IP: 1
72.16.1.1^[[07;00HGATEWAY IP:
172.16.1.1
^[[08;00HPXE Loader
1.00^[[2JM-^@^[[01;00H^[[0
m^[[2m^[[0m^[[2;30;40m
^@^[[0m^[[2;37;40m
^[[02;00H^[[0m^[[2;30;40m
So it really doesn't seem to get very far at all.
I've bisected and confirmed that the problem was introduced in r239066. I
tried reverting that commit locally and I can boot fine again. I took a
quick look at that commit but it appears to be way over my head. I'm
willing to test patches or gather more debugging information; this thing
isn't going anywhere until I can get it booting. :)
I have one of these X8DT6 systems. It has grub2 as the primary boot
loader which then loads zfsloader. Many weeks back I updated the BIOS,
grub, and FreeBSD and ran into a similar problem -- zfsloader would
start, print a few messages, and then the system would reboot. I
tracked it down to the int 0x13 call (with eax=0x4800) in bd_int13probe.
It would walk past the end of the edd_params structure and corrupt the
return address on the stack. I worked around it by padding edd_params.
I was planning to debug it further to find out which of the 3 things
that were updated caused the problem but Other Things(tm) came up. See
if this works for you too:
diff -r d35d326e437a -r e5228169f3f1 sys/boot/i386/common/edd.h
--- a/sys/boot/i386/common/edd.hTue Oct 30 21:51:09 2012 -0700
+++ b/sys/boot/i386/common/edd.hTue Oct 30 21:51:20 2012 -0700
@@ -62,6 +62,7 @@ struct edd_params {
uint16_tsector_size;
uint16_tedd_params_seg;
uint16_tedd_params_off;
+ charpad[64];
};
Regards,
Navdeep
___
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
