Re: using ConnectX card as Ethernet (mlxen)
Hi, On 2014-1-20, at 21:59, John Baldwin j...@freebsd.org wrote: I believe this should work, yes. Getting a crashdump or the panic messages would be really helpful in figuring out why it isn't. Thanks. I rebuilt the kernel, and see no crashes anymore. So that's good. But there are a bunch of other issues that maybe someone has some ideas about: (1) Late attach The ConnectX-3 attaches very late during the boot process, after the system is already in single-user mode. See the attached dmesg; pci17 and pci18 (there are two identical cards in this system) first show as no driver attached during the PCI bus enumeration. Only after the system is single-user mode does the mlx4_core attach to the cards. That means that e.g. trying to set sysctls for these cards in /etc/sysctl.conf, or configuring their IP addresses via rc.conf is not possible. At the moment, I work around this by sleeping in rc.local and then doing assignments there, but that's a hack. Any clues why these cards attach so late? (2) Device numbers change After booting, these cards show up in InfiniBand mode: ib0: flags=8002BROADCAST,MULTICAST metric 0 mtu 65520 options=80018VLAN_MTU,VLAN_HWTAGGING,LINKSTATE lladdr 80.0.0.48.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d1.21 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL ib1: flags=8002BROADCAST,MULTICAST metric 0 mtu 65520 options=80018VLAN_MTU,VLAN_HWTAGGING,LINKSTATE lladdr 80.0.0.49.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d1.22 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL ib2: flags=8002BROADCAST,MULTICAST metric 0 mtu 65520 options=80018VLAN_MTU,VLAN_HWTAGGING,LINKSTATE lladdr 80.0.0.48.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d1 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL ib3: flags=8002BROADCAST,MULTICAST metric 0 mtu 65520 options=80018VLAN_MTU,VLAN_HWTAGGING,LINKSTATE lladdr 80.0.0.49.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d2 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL Then I force one into Ethernet mode: # sysctl sys.device.mlx4_core0.mlx4_port1=eth sys.device.mlx4_core0.mlx4_port1: auto (ib) - eth and the device numbers on the ib devices change: ib1 is now ib4, and I have a new mlxen0 device. ib2: flags=8002BROADCAST,MULTICAST metric 0 mtu 65520 options=80018VLAN_MTU,VLAN_HWTAGGING,LINKSTATE lladdr 80.0.0.48.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d1 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL ib3: flags=8002BROADCAST,MULTICAST metric 0 mtu 65520 options=80018VLAN_MTU,VLAN_HWTAGGING,LINKSTATE lladdr 80.0.0.49.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d2 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL mlxen0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=d05bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE ether f4:52:14:10:d1:21 inet6 fe80::f652:14ff:fe10:d121%mlxen0 prefixlen 64 scopeid 0xe nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect status: no carrier ib4: flags=8002BROADCAST,MULTICAST metric 0 mtu 65520 options=80018VLAN_MTU,VLAN_HWTAGGING,LINKSTATE lladdr 80.0.0.4a.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d1.22 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL When I change another port into Ethernet mode # sysctl sys.device.mlx4_core0.mlx4_port2=eth sys.device.mlx4_core0.mlx4_port2: auto (ib) - eth device numbers change again. Now mxlen0 disappears and becomes mxlen1, and I have a new mxlen2 device: ib2: flags=8002BROADCAST,MULTICAST metric 0 mtu 65520 options=80018VLAN_MTU,VLAN_HWTAGGING,LINKSTATE lladdr 80.0.0.48.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d1 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL ib3: flags=8002BROADCAST,MULTICAST metric 0 mtu 65520 options=80018VLAN_MTU,VLAN_HWTAGGING,LINKSTATE lladdr 80.0.0.49.fe.80.0.0.0.0.0.0.f4.52.14.3.0.10.d0.d2 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL mlxen1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=d05bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE ether f4:52:14:10:d1:21 inet6 fe80::f652:14ff:fe10:d121%mlxen1 prefixlen 64 scopeid 0xe nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect status: no carrier mlxen2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=d05bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE ether f4:52:14:10:d1:22 inet6 fe80::f652:14ff:fe10:d122%mlxen2 prefixlen 64 scopeid 0xf nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect status: no carrier Changing the other two ports (on the second card) to Ethernet mode # sysctl sys.device.mlx4_core1.mlx4_port1=eth sys.device.mlx4_core1.mlx4_port1: auto (ib) -
Re: using ConnectX card as Ethernet (mlxen)
On 2014-1-21, at 10:04, Lars Eggert l...@netapp.com wrote: See the attached dmesg which I of course forget to attach (sigh). See below. Lars GDB: no debug ports present970 KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 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 11.0-CURRENT #8 ab08c30(fas3270)-dirty: Tue Jan 21 09:07:36 CET 2014 el...@stanley.muccbc.hq.netapp.com:/usr/home/elars/obj/usr/home/elars/src/sys/FAS3270 amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Xeon(R) CPU E5240 @ 3.00GHz (3000.17-MHz K8-class CPU) Origin=GenuineIntel Id=0x1067a Family=0x6 Model=0x17 Stepping=10 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=0xc0ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,OSXSAVE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 18253611008 (17408 MB) avail memory = 16599695360 (15830 MB) MPTable: NETAPP SB_XVI Event timer LAPIC quality 400 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 random device not loaded; using insecure entropy ioapic0: Assuming intbase of 0 ioapic0 Version 2.0 irqs 0-23 on motherboard netmap: loaded module random: Software, Yarrow initialized smbios0: System Management BIOS at iomem 0xf6c00-0xf6c1e on motherboard smbios0: Version: 2.5 cryptosoft0: software crypto on motherboard pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: MPTable PCI-PCI bridge at device 2.0 on pci0 pci1: PCI bus on pcib1 cxgbc0: Carnegie T3 onboard SR KR, 2 ports mem 0xdd001000-0xdd001fff,0xdc80-0xdcff,0xdd00-0xdd000fff irq 16 at device 0.0 on pci1 cxgbc0: AD8158 0xf=0x3 0x1=0xf cxgbc0: using MSI-X interrupts (9 vectors) cxgb0: Port 0 10GBASE-R on cxgbc0 cxgb0: Ethernet address: 00:a0:98:30:c2:2a cxgb1: Port 1 10GBASE-R on cxgbc0 cxgb1: Ethernet address: 00:a0:98:30:c2:2b cxgbc0: Firmware Version 7.11.0 pcib2: PCI-PCI bridge at device 3.0 on pci0 pci2: PCI bus on pcib2 pcib3: MPTable PCI-PCI bridge at device 4.0 on pci0 pci3: PCI bus on pcib3 pcib4: PCI-PCI bridge mem 0xdd30-0xdd31 irq 16 at device 0.0 on pci3 pci4: PCI bus on pcib4 pcib3: unable to route slot 0 INTB pcib5: PCI-PCI bridge irq 16 at device 4.0 on pci4 pci5: PCI bus on pcib5 pcib6: MPTable PCI-PCI bridge irq 10 at device 5.0 on pci4 pci6: PCI bus on pcib6 ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.15 mem 0xdd40-0xdd47,0xdd50-0xdd503fff irq 17 at device 0.0 on pci6 ix0: Using MSIX interrupts with 5 vectors ix0: Ethernet address: 90:e2:ba:37:d5:b4 ix0: PCI Express Bus: Speed 5.0GT/s Width x8 001.08 [2141] netmap_attach success for ix0 ix1: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.15 mem 0xdd48-0xdd4f,0xdd504000-0xdd507fff irq 18 at device 0.1 on pci6 ix1: Using MSIX interrupts with 5 vectors ix1: Ethernet address: 90:e2:ba:37:d5:b5 ix1: PCI Express Bus: Speed 5.0GT/s Width x8 001.09 [2141] netmap_attach success for ix1 pcib7: PCI-PCI bridge irq 16 at device 8.0 on pci4 pci7: PCI bus on pcib7 pcib8: PCI-PCI bridge at device 0.0 on pci7 pci8: PCI bus on pcib8 pcib9: MPTable PCI-PCI bridge at device 0.0 on pci8 pci9: PCI bus on pcib9 em0: Intel(R) PRO/1000 Network Connection 7.3.8 mem 0xdd62-0xdd63,0xdd60-0xdd61 irq 16 at device 0.0 on pci9 em0: Using an MSI interrupt em0: Ethernet address: 00:1b:21:a8:a5:34 001.10 [2141] netmap_attach success for em0 em1: Intel(R) PRO/1000 Network Connection 7.3.8 mem 0xdd66-0xdd67,0xdd64-0xdd65 irq 17 at device 0.1 on pci9 em1: Using an MSI interrupt em1: Ethernet address: 00:1b:21:a8:a5:35 001.11 [2141] netmap_attach success for em1 pcib10: MPTable PCI-PCI bridge at device 1.0 on pci8 pci10: PCI bus on pcib10 em2: Intel(R) PRO/1000 Network Connection 7.3.8 mem 0xdd72-0xdd73,0xdd70-0xdd71 irq 17 at device 0.0 on pci10 em2: Using an MSI interrupt em2: Ethernet address: 00:1b:21:a8:a5:36 001.12 [2141] netmap_attach success for em2 em3: Intel(R) PRO/1000 Network Connection 7.3.8 mem 0xdd76-0xdd77,0xdd74-0xdd75 irq 18 at device 0.1 on pci10 em3: Using an MSI interrupt em3: Ethernet address: 00:1b:21:a8:a5:37 001.13 [2141] netmap_attach success for em3 pcib11: PCI-PCI bridge at device 5.0 on pci0 pci11: PCI bus on pcib11 pcib12: PCI-PCI bridge at device 6.0 on pci0 pci12: PCI bus on pcib12 pcib0: unable to
Re: using ConnectX card as Ethernet (mlxen)
Last follow-up: I just saw that there are some additional messages (errors?) on the serial console when changing the device from IB to Ethernet, maybe they mean something to someone: root@one:~ # sysctl sys.device.mlx4_core0.mlx4_port1=eth sys.device.mlx4_core0.mlx4_port1: auto (ib)7ib0: stopping interface 7ib0: downing ib_dev 7ib0: stopping multicast thread 7ib0: flushing multicast list 7qpn 0x48: invalid attribute mask specified for transition 0 to 6. qp_type 4, attr_mask 0x1\n4ib0: Failed to modify QP to ERROR state 7ib0: All sends and receives done. 7ib0: cleaning up ib_dev 7ib0: stopping multicast thread 7ib0: flushing multicast list 7ib0: Cleanup ipoib connected mode. 7ib1: stopping interface 7ib1: downing ib_dev 7ib1: stopping multicast thread 7ib1: flushing multicast list 7qpn 0x49: invalid attribute mask specified for transition 0 to 6. qp_type 4, attr_mask 0x1\n4ib1: Failed to modify QP to ERROR state 7ib1: All sends and receives done. 7ib1: cleaning up ib_dev 7ib1: stopping multicast thread 7ib1: flushing multicast list 7ib1: Cleanup ipoib connected mode. 6mlx4_en mlx4_core0: Using 5 tx rings for port:1 6mlx4_en mlx4_core0: Defaulting to 4 rx rings for port:1 6mlx4_en mlx4_core0: Activating port:1 mlxen0: Ethernet address: f4:52:14:10:d1:21 4mlx4_en: mlx4_core0: Port 1: Using 5 TX rings 4mlx4_en: mlx4_core0: Port 1: Using 4 RX rings 6mlx4_ib: Mellanox ConnectX InfiniBand driver v1.Jan 21 09:21:31 0 (April 4, 2008) one kernel: mlx4_en: mlx4_core0: Port 1: Using 5 TX rings Jan 7ib4: max_srq_sge=31 21 09:21:31 one 7ib4: max_cm_mtu = 0x1, num_frags=16 kernel: mlx4_en:ib4: mlx4_core0: PorAttached to mlx4_0 port 2 t 1: Using 4 RX rings - eth Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problem updating bootcode on ZFS on root system with MBR
On 20.01.2014 23:32, Thomas Hoffmann wrote: I am running 11.0-CURRENT (r260850) with zfs on root with MBR. After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850) my zpools reported that they needed to be upgraded. So, I upgraded my zpools and I am attempting to update the bootcode (as required). I managed to get the boot1 stage code updated, but cannot get the boot2 stage code updated. Here is what I have done: # sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 - 16 # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.014996 secs (34142 bytes/sec) # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 bootcode written to ada0s1 # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 dd: /dev/ada0s1a: Operation not permitted The final dd statement fails with operation not permitted. In all my research, understood the initial sysctl command I ran would prevent this particular error from happening. What do I need to do to get the boot2 code written to /dev/ada0s1a? This will work only if ada0s1a isn't in use. The debugflags trick works only for whole disk, i.e. for geoms with rank=1. Another way is calculate needed offset and write bootcode directly to ada0. -- WBR, Andrey V. Elsukov ___ 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: Problem updating bootcode on ZFS on root system with MBR
on 21/01/2014 11:35 Andrey V. Elsukov said the following: On 20.01.2014 23:32, Thomas Hoffmann wrote: I am running 11.0-CURRENT (r260850) with zfs on root with MBR. After upgrading my 10.0-RELEASE (r260669) system to 11.0-CURRENT (r260850) my zpools reported that they needed to be upgraded. So, I upgraded my zpools and I am attempting to update the bootcode (as required). I managed to get the boot1 stage code updated, but cannot get the boot2 stage code updated. Here is what I have done: # sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 - 16 # dd if=/boot/zfsboot of=/tmp/zfsboot1 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.014996 secs (34142 bytes/sec) # gpart bootcode -b /tmp/zfsboot1 /dev/ada0s1 bootcode written to ada0s1 # dd if=/boot/zfsboot of=/dev/ada0s1a skip=1 seek=1024 dd: /dev/ada0s1a: Operation not permitted The final dd statement fails with operation not permitted. In all my research, understood the initial sysctl command I ran would prevent this particular error from happening. What do I need to do to get the boot2 code written to /dev/ada0s1a? This will work only if ada0s1a isn't in use. The debugflags trick works only for whole disk, i.e. for geoms with rank=1. Another way is calculate needed offset and write bootcode directly to ada0. And ultimately we should extend our ZFS interface with an ioctl to write a blob to a boot code area of a specified ZFS leaf vdev. This would the right way to install zfsboot. -- 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: Problem updating bootcode on ZFS on root system with MBR
On 21.01.2014 14:45, Andriy Gapon wrote: What do I need to do to get the boot2 code written to /dev/ada0s1a? This will work only if ada0s1a isn't in use. The debugflags trick works only for whole disk, i.e. for geoms with rank=1. Another way is calculate needed offset and write bootcode directly to ada0. And ultimately we should extend our ZFS interface with an ioctl to write a blob to a boot code area of a specified ZFS leaf vdev. This would the right way to install zfsboot. Hi Andriy, do you have some patches to test? :-) -- WBR, Andrey V. Elsukov ___ 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: Regression on 10-RC5 with a multicast routing daemon
On Sun, Jan 19, 2014 at 02:42:32AM +0100, Olivier Cochard-Labbé wrote:
OOlivier,
O
O
O TL;DR version: you need not subtract iphdrlen in 10.0. Code in
O igmp.c:accept_igmp()
O should be smth like:
O
O iphdrlen = ip-ip_hl 2;
O #ifdef RAW_INPUT_IS_RAW /* Linux */
O ipdatalen = ntohs(ip-ip_len) - iphdrlen;
O #else
O #if __FreeBSD_version = 100
O ipdatalen = ip-ip_len - iphdrlen;
O #else
O ipdatalen = ip-ip_len;
O #endif
O #endif
O
O
O With this patch I've no more the message warning - Received packet from
O x.x.x.x shorter (28 bytes) than hdr+data length (20+28):Thanks!
O But there is still a regression regarding the PIM socket behavior not
O related to the packet format.
O The pim.c include 2 functions (pim_read and pim_accept) that are called
O when the socket received a packet: There functions are never triggered when
O PIM packets are received on 10.0.
O In the same time igmp_read() and igmp_accept() are correctly triggered on
O 9.2 and 10.0.
O tcpdump in non-promiscious mode correctly see input of PIM packet: This
O should confirm that once this daemon is started, it correctly open a PIM
O socket and the multicast filter is updated.
Can you please try this patch to kernel?
If it doesn't work, can you please gather ktr(4) information with KTR_IPMF
compiled into kernel.
--
Totus tuus, Glebius.
Index: sys/netinet/ip_mroute.c
===
--- sys/netinet/ip_mroute.c (revision 260904)
+++ sys/netinet/ip_mroute.c (working copy)
@@ -2557,14 +2557,13 @@ pim_encapcheck(const struct mbuf *m, int off, int
* is passed to if_simloop().
*/
void
-pim_input(struct mbuf *m, int off)
+pim_input(struct mbuf *m, int iphlen)
{
struct ip *ip = mtod(m, struct ip *);
struct pim *pim;
int minlen;
-int datalen = ntohs(ip-ip_len);
+int datalen = ntohs(ip-ip_len) - iphlen;
int ip_tos;
-int iphlen = off;
/* Keep statistics */
PIMSTAT_INC(pims_rcv_total_msgs);
@@ -2594,8 +2593,7 @@ void
* Get the IP and PIM headers in contiguous memory, and
* possibly the PIM REGISTER header.
*/
-if ((m-m_flags M_EXT || m-m_len minlen)
- (m = m_pullup(m, minlen)) == 0) {
+if (m-m_len minlen (m = m_pullup(m, minlen)) == 0) {
CTR1(KTR_IPMF, %s: m_pullup() failed, __func__);
return;
}
___
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
freebsd-update
Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? signature.asc Description: OpenPGP digital signature
Re: freebsd-update
On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( Hopefully someone suggests something better, but yes I do see these as well :( Best Regards, Antonio ___ 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: freebsd-update
On 21 Jan 2014, at 07:13, Antonio Olivares olivares14...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2-10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? David ___ 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: Problem updating bootcode on ZFS on root system with MBR
on 21/01/2014 13:18 Andrey V. Elsukov said the following:
On 21.01.2014 14:45, Andriy Gapon wrote:
What do I need to do to get the boot2 code written to /dev/ada0s1a?
This will work only if ada0s1a isn't in use. The debugflags trick works
only for whole disk, i.e. for geoms with rank=1. Another way is
calculate needed offset and write bootcode directly to ada0.
And ultimately we should extend our ZFS interface with an ioctl to write a
blob
to a boot code area of a specified ZFS leaf vdev. This would the right way
to
install zfsboot.
Hi Andriy,
do you have some patches to test? :-)
I don't, but the following patch can serve as a very good example.
It adds an ioctl that serves a slightly different but quite similar purpose:
commit 54802d6659ec134fd221c3daaa8fdf9cee985d39
Author: Andriy Gapon a...@icyb.net.ua
Date: Fri Sep 14 23:15:43 2012 +0300
[wip] zfs: add a new ioctl that allows to place text data into pad2 area
The data is placed into Pad2 area of the first vdev label of a given
vdev in a given pool.
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
index fb30ea9..4a46cc2 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
@@ -162,6 +162,8 @@ typedef enum {
extern int vdev_label_init(vdev_t *vd, uint64_t txg, vdev_labeltype_t reason);
+extern int vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t size);
+
#ifdef __cplusplus
}
#endif
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
index c7dd3ad..55c87d8 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
@@ -855,6 +855,44 @@ retry:
return (error);
}
+int
+vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t size)
+{
+ spa_t *spa = vd-vdev_spa;
+ zio_t *zio;
+ char *pad2;
+ int flags = ZIO_FLAG_CONFIG_WRITER | ZIO_FLAG_CANFAIL;
+ int error;
+
+ if (size VDEV_PAD_SIZE)
+ return (EINVAL);
+
+ if (!vd-vdev_ops-vdev_op_leaf)
+ return (ENODEV);
+ if (vdev_is_dead(vd))
+ return (ENXIO);
+
+ ASSERT(spa_config_held(spa, SCL_ALL, RW_WRITER) == SCL_ALL);
+
+ pad2 = zio_buf_alloc(VDEV_PAD_SIZE);
+ bzero(pad2, VDEV_PAD_SIZE);
+ memcpy(pad2, buf, size);
+
+retry:
+ zio = zio_root(spa, NULL, NULL, flags);
+ vdev_label_write(zio, vd, 0, pad2,
+ offsetof(vdev_label_t, vl_pad2),
+ VDEV_PAD_SIZE, NULL, NULL, flags);
+ error = zio_wait(zio);
+ if (error != 0 !(flags ZIO_FLAG_TRYHARD)) {
+ flags |= ZIO_FLAG_TRYHARD;
+ goto retry;
+ }
+
+ zio_buf_free(pad2, VDEV_PAD_SIZE);
+ return (error);
+}
+
/*
* ==
* uberblock load/sync
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
index e208ed8..ff90839 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
@@ -3404,6 +3404,53 @@ zfs_ioc_log_history(const char *unused, nvlist_t *innvl,
nvlist_t *outnvl)
return (error);
}
+#ifdef __FreeBSD__
+static int
+zfs_ioc_nextboot(const char *unused, nvlist_t *innvl, nvlist_t *outnvl)
+{
+ char name[MAXNAMELEN];
+ spa_t *spa;
+ vdev_t *vd;
+ char *command;
+ uint64_t pool_guid;
+ uint64_t vdev_guid;
+ int error;
+
+ if (nvlist_lookup_uint64(innvl,
+ ZPOOL_CONFIG_POOL_GUID, pool_guid) != 0)
+ return (EINVAL);
+ if (nvlist_lookup_uint64(innvl,
+ ZPOOL_CONFIG_GUID, vdev_guid) != 0)
+ return (EINVAL);
+ if (nvlist_lookup_string(innvl,
+ command, command) != 0)
+ return (EINVAL);
+
+ mutex_enter(spa_namespace_lock);
+ spa = spa_by_guid(pool_guid, vdev_guid);
+ if (spa != NULL)
+ strcpy(name, spa_name(spa));
+ mutex_exit(spa_namespace_lock);
+ if (spa == NULL)
+ return (ENOENT);
+
+ if ((error = spa_open(name, spa, FTAG)) != 0)
+ return (error);
+ spa_vdev_state_enter(spa, SCL_ALL);
+ vd = spa_lookup_by_guid(spa, vdev_guid, B_TRUE);
+ if (vd == NULL) {
+ (void) spa_vdev_state_exit(spa, NULL, ENXIO);
+ spa_close(spa, FTAG);
+ return (ENODEV);
+ }
+ error = vdev_label_write_pad2(vd, command, strlen(command));
+ (void) spa_vdev_state_exit(spa, NULL, 0);
+ txg_wait_synced(spa-spa_dsl_pool, 0);
+ spa_close(spa, FTAG);
+ return (error);
+}
+#endif
+
/*
Re: freebsd-update
On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: On 21 Jan 2014, at 07:13, Antonio Olivares olivares14...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2-10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? AFAIK it doesn't use mergemaster? I thought it used its own tool? I really want to figure out a way to let it use etcupdate instead since it handles this case even for locally modified files cleanly. -- 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: Regression on 10-RC5 with a multicast routing daemon
On Wednesday, January 15, 2014 6:34:30 am Gleb Smirnoff wrote: Damn, what a mess. I'd like to go towards absolutely unmodified packets for the 11-release cycle. I agree. -- 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: [CFT] xboxfb with vt(9) (a.k.a. newcons)
On Wednesday, January 15, 2014 6:47:36 pm Aleksandr Rybalko wrote: On Wed, 15 Jan 2014 23:35:39 + Ed Schouten edschou...@gmail.com wrote: Hello there, On Wed Jan 15 2014 at 1:43:56 PM, Aleksandr Rybalko r...@freebsd.org wrote: I've just committed update to xboxfb driver for vt(9). But I have no HW to test on. So if anybody have HW and time/wish to test it, please help me. As I also mentioned to you privately, I think it might actually be wiser to just drop Xbox support entirely. The Xbox support was a funny thing back then, but I suspect it has actually outlived its usefulness. The original Xbox only has a 733 MHz Celeron CPU, 64 MB of RAM and a 10 GB harddisk. I don't think there are that many people left who want to run FreeBSD 11 on it. Thoughts? Ed Hi folks! Ed, Raspberry-Pi has more RAM, almost same CPU clock and no HDD at all and people use it :) Since it already in HEAD I would prefer to left it here for some time. So other will be able to use it as example. But even for that better to know if it works, to not waste time of users or hackers who will try to use it. :) If you don't find anyone who is able to test this, then you probably should remove it. If someone steps up to test it, then it can stay, but it is hard to keep code around that no one tests. -- 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: [PATCH RFC 05/13] xen: implement Xen IO APIC ops
On Tuesday, December 24, 2013 6:20:54 am Roger Pau Monne wrote:
Implement a different set of hooks for IO APIC to use when running
under Xen Dom0.
---
sys/x86/xen/pv.c | 44
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
index ab4afba..e5ad200 100644
--- a/sys/x86/xen/pv.c
+++ b/sys/x86/xen/pv.c
@@ -49,6 +49,7 @@ __FBSDID($FreeBSD$);
#include vm/vm_pager.h
#include vm/vm_param.h
+#include x86/apicreg.h
#include machine/sysarch.h
#include machine/clock.h
#include machine/pc/bios.h
@@ -58,6 +59,7 @@ __FBSDID($FreeBSD$);
#include xen/xen-os.h
#include xen/hypervisor.h
#include xen/pv.h
+#include xen/xen_intr.h
#include xen/interface/vcpu.h
@@ -73,6 +75,11 @@ static caddr_t xen_pv_parse_preload_data(u_int64_t);
static void xen_pv_parse_memmap(caddr_t, vm_paddr_t *, int *);
static void xen_pv_set_init_ops(void);
+
+static u_int xen_pv_ioapic_read(volatile ioapic_t *, int);
+static void xen_pv_ioapic_write(volatile ioapic_t *, int, u_int);
+static void xen_pv_ioapic_register_intr(struct ioapic_intsrc *);
+
/* Extern Declarations
---*/
/* Variables used by amd64 mp_machdep to start APs */
extern struct mtx ap_boot_mtx;
@@ -92,6 +99,13 @@ struct init_ops xen_init_ops = {
.parse_memmap = xen_pv_parse_memmap,
};
+/* Xen ioapic_ops implementation */
+struct ioapic_ops xen_ioapic_ops = {
+ .read = xen_pv_ioapic_read,
+ .write =xen_pv_ioapic_write,
+ .register_intr =xen_pv_ioapic_register_intr,
+};
+
static struct
{
const char *ev;
@@ -342,6 +356,34 @@ xen_pv_parse_memmap(caddr_t kmdp, vm_paddr_t *physmap,
int *physmap_idx)
bios_add_smap_entries(xen_smap, size, physmap, physmap_idx);
}
+static u_int
+xen_pv_ioapic_read(volatile ioapic_t *apic, int reg)
+{
+ struct physdev_apic apic_op;
+ int rc;
+
+ mtx_assert(icu_lock, MA_OWNED);
+
+ apic_op.apic_physbase = pmap_kextract((vm_offset_t) apic);
Seems a shame to have to do this. I wouldn't mind if you changed the
read/write callbacks to take 'struct ioapic *' instead and then use the
'io_paddr' member. I do think that would be cleaner.
+ apic_op.reg = reg;
+ rc = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, apic_op);
+ if (rc)
+ panic(apic_read operation failed);
+
+ return (apic_op.value);
+}
+
+static void
+xen_pv_ioapic_write(volatile ioapic_t *apic, int reg, u_int val)
+{
+}
I guess not allowing writes is on purpose?
+
+static void
+xen_pv_ioapic_register_intr(struct ioapic_intsrc *pin)
+{
+ xen_register_pirq(pin-io_irq, pin-io_activehi, pin-io_edgetrigger);
+}
+
static void
xen_pv_set_init_ops(void)
{
@@ -349,4 +391,6 @@ xen_pv_set_init_ops(void)
init_ops = xen_init_ops;
/* Disable lapic */
lapic_disabled = true;
+ /* IOAPIC ops for Xen PV */
+ ioapic_ops = xen_ioapic_ops;
}
--
1.7.7.5 (Apple Git-26)
--
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: [PATCH RFC 02/13] ioapic: introduce hooks for some ioapic ops
On Tuesday, December 24, 2013 6:20:51 am Roger Pau Monne wrote: Create some hooks for IO APIC operations that will diverge from bare metal when implemented for Xen Dom0. This patch should not introduce any changes in functionality, it's a preparatory patch for the implementation of the Xen IO APIC hooks. I think this is fine. I should really create a sys/x86/include/apicvar.h as there is a lot shared between those two headers. -- 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: [PATCH RFC 01/13] xen: use the hardware e820 map on Dom0
On Tuesday, December 24, 2013 6:20:50 am Roger Pau Monne wrote:
We need to do some tweaking of the hardware e820 map, since the memory
layout provided by Xen and the e820 map doesn't match.
This consists in clamping the e820 map so that regions above max_pfn
are marked as unusuable.
---
sys/x86/xen/pv.c | 35 +--
1 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
index 4f7415e..ab4afba 100644
--- a/sys/x86/xen/pv.c
+++ b/sys/x86/xen/pv.c
@@ -297,17 +297,48 @@ static void
xen_pv_parse_memmap(caddr_t kmdp, vm_paddr_t *physmap, int *physmap_idx)
{
struct xen_memory_map memmap;
+ unsigned long max_pfn = HYPERVISOR_start_info-nr_pages;
+ u_int64_t mem_end = ptoa(max_pfn);
u_int32_t size;
- int rc;
+ int rc, mem_op, i;
One minor nit is that it is preferred to not initalize variables in
declarations style-wise. Aside from that, this looks fine to me.
/* Fetch the E820 map from Xen */
memmap.nr_entries = MAX_E820_ENTRIES;
set_xen_guest_handle(memmap.buffer, xen_smap);
- rc = HYPERVISOR_memory_op(XENMEM_memory_map, memmap);
+ mem_op = xen_initial_domain() ?
+ XENMEM_machine_memory_map :
+ XENMEM_memory_map;
+ rc = HYPERVISOR_memory_op(mem_op, memmap);
if (rc)
panic(unable to fetch Xen E820 memory map);
size = memmap.nr_entries * sizeof(xen_smap[0]);
+ /*
+ * This should be improved, Xen provides us with a single
+ * chunk of physical memory that goes from 0 to max_pfn,
+ * and what we do here is clamp the HW memory map to make
+ * sure regions above max_pfn are marked as reserved.
+ *
+ * TRTTD would be to move the memory not used because of
+ * the holes in the HW memory map to the now clamped regions
+ * using XENMEM_{decrease/increase}_reservation.
+ */
+ for (i = 0; i memmap.nr_entries; i++) {
+ u_int64_t end = xen_smap[i].base + xen_smap[i].length;
+ if (xen_smap[i].type == SMAP_TYPE_MEMORY) {
+ if (xen_smap[i].base mem_end) {
+ /* Mark as reserved */
+ xen_smap[i].type = SMAP_TYPE_RESERVED;
+ continue;
+ }
+ if (end mem_end) {
+ /* Truncate region */
+ xen_smap[i].length -= end - mem_end;
+ }
+ }
+ }
+
+
bios_add_smap_entries(xen_smap, size, physmap, physmap_idx);
}
--
1.7.7.5 (Apple Git-26)
--
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: [PATCH RFC 06/13] xen: Dom0 console fixes
On Tuesday, December 24, 2013 6:20:55 am Roger Pau Monne wrote: Minor fixes and workarounds to make the Xen Dom0 console work. Looks ok to me. -- 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: [PATCH RFC 04/13] xen: implement basic PIRQ support for Dom0
On Tuesday, December 24, 2013 6:20:53 am Roger Pau Monne wrote: This allows Dom0 to manage physical hardware, redirecting the physical interrupts to event channels. --- sys/x86/xen/xen_intr.c | 190 +-- sys/xen/xen_intr.h | 11 +++ 2 files changed, 192 insertions(+), 9 deletions(-) diff --git a/sys/x86/xen/xen_intr.c b/sys/x86/xen/xen_intr.c index bc0781e..340e5ed 100644 --- a/sys/x86/xen/xen_intr.c +++ b/sys/x86/xen/xen_intr.c @@ -104,6 +104,8 @@ DPCPU_DECLARE(struct vcpu_info *, vcpu_info); #define is_valid_evtchn(x) ((x) != 0) +#define EEXIST 17 /* Xen already exists error */ Is there a xen_errno.h header? Might be nice to have one and give these constants unique names (e.g. XEN_EEXIST or some such) to avoid confusion/conflicts with sys/errno.h. Other than that I think this looks fine. -- 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: FreeBSD 10 and zfsd
On Thu, Dec 19, 2013 at 6:32 PM, asom...@gmail.com wrote: On Wed, Dec 18, 2013 at 2:40 PM, Outback Dingo outbackdi...@gmail.com wrote: On Wed, Dec 18, 2013 at 4:40 PM, Alan Somers asom...@freebsd.org wrote: On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo outbackdi...@gmail.com wrote: On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder f...@freebsd.org wrote: On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote: Due to popular demand, I have located a round toit. I'm currently working on rebasing the zfsd project branch to head, after which I'll push SpectraLogic's recent changes. Just thought I'd ping the list about the situation here... would love to see this in HEAD soon :) Id love to see an updated patch from the zfsd tree against head itself so we could continue using and testing it Coming up ... Sweet..!!! Sorry, but I'm running into nontrivial merge conflicts. It's going to take a few more days. -Alan Has any progress been made on an updated patch set ?? ___ 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 ___ 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: FreeBSD 10 and zfsd
On Tue, Jan 21, 2014 at 12:37 PM, Outback Dingo outbackdi...@gmail.com wrote: On Thu, Dec 19, 2013 at 6:32 PM, asom...@gmail.com wrote: On Wed, Dec 18, 2013 at 2:40 PM, Outback Dingo outbackdi...@gmail.com wrote: On Wed, Dec 18, 2013 at 4:40 PM, Alan Somers asom...@freebsd.org wrote: On Wed, Dec 18, 2013 at 11:47 AM, Outback Dingo outbackdi...@gmail.com wrote: On Wed, Dec 18, 2013 at 12:39 PM, Mark Felder f...@freebsd.org wrote: On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote: Due to popular demand, I have located a round toit. I'm currently working on rebasing the zfsd project branch to head, after which I'll push SpectraLogic's recent changes. Just thought I'd ping the list about the situation here... would love to see this in HEAD soon :) Id love to see an updated patch from the zfsd tree against head itself so we could continue using and testing it Coming up ... Sweet..!!! Sorry, but I'm running into nontrivial merge conflicts. It's going to take a few more days. -Alan Has any progress been made on an updated patch set ?? Yes, but not any visible progress. I had to make some changes to devd and libdevctl, and I'm currently blocked by this bug. I have a tentative solution for it, and I hope to start a discussion on freebsd-net about it today or tomorrow. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/185813 -Alan ___ 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 ___ 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: freebsd-update
On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin j...@freebsd.org wrote: On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: On 21 Jan 2014, at 07:13, Antonio Olivares olivares14...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2-10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? AFAIK it doesn't use mergemaster? I thought it used its own tool? I really want to figure out a way to let it use etcupdate instead since it handles this case even for locally modified files cleanly. Having just gone through this on a 10.0-rc5 to 10.0-RELEASE run, I can assure you that it is not completely fixed. One huge part is fixed... every file's ID line is no longer is changed on every release. OTOH, for files that are modified, thy still show up. It hit many of the sendmail .cf files. Annoying as I don't even use sendmail. Not sure if there was a good reason Colin re-invented the wheel on this. It does not use mergemaster or even a reasonable differences editor such as the one mergemaster uses. Just going to the mergemaster code for handling diffs would be a HUGE win. I am getting really tired of /CR3dddwnddn. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.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: Problem updating bootcode on ZFS on root system with MBR
On Tue, Jan 21, 2014 at 10:47 AM, Andriy Gapon a...@freebsd.org wrote:
on 21/01/2014 13:18 Andrey V. Elsukov said the following:
On 21.01.2014 14:45, Andriy Gapon wrote:
What do I need to do to get the boot2 code written to /dev/ada0s1a?
This will work only if ada0s1a isn't in use. The debugflags trick works
only for whole disk, i.e. for geoms with rank=1. Another way is
calculate needed offset and write bootcode directly to ada0.
And ultimately we should extend our ZFS interface with an ioctl to
write a blob
to a boot code area of a specified ZFS leaf vdev. This would the right
way to
install zfsboot.
Hi Andriy,
do you have some patches to test? :-)
I don't, but the following patch can serve as a very good example.
It adds an ioctl that serves a slightly different but quite similar
purpose:
commit 54802d6659ec134fd221c3daaa8fdf9cee985d39
Author: Andriy Gapon a...@icyb.net.ua
Date: Fri Sep 14 23:15:43 2012 +0300
[wip] zfs: add a new ioctl that allows to place text data into pad2
area
The data is placed into Pad2 area of the first vdev label of a given
vdev in a given pool.
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
index fb30ea9..4a46cc2 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/vdev.h
@@ -162,6 +162,8 @@ typedef enum {
extern int vdev_label_init(vdev_t *vd, uint64_t txg, vdev_labeltype_t
reason);
+extern int vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t
size);
+
#ifdef __cplusplus
}
#endif
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
index c7dd3ad..55c87d8 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
@@ -855,6 +855,44 @@ retry:
return (error);
}
+int
+vdev_label_write_pad2(vdev_t *vd, const char *buf, size_t size)
+{
+ spa_t *spa = vd-vdev_spa;
+ zio_t *zio;
+ char *pad2;
+ int flags = ZIO_FLAG_CONFIG_WRITER | ZIO_FLAG_CANFAIL;
+ int error;
+
+ if (size VDEV_PAD_SIZE)
+ return (EINVAL);
+
+ if (!vd-vdev_ops-vdev_op_leaf)
+ return (ENODEV);
+ if (vdev_is_dead(vd))
+ return (ENXIO);
+
+ ASSERT(spa_config_held(spa, SCL_ALL, RW_WRITER) == SCL_ALL);
+
+ pad2 = zio_buf_alloc(VDEV_PAD_SIZE);
+ bzero(pad2, VDEV_PAD_SIZE);
+ memcpy(pad2, buf, size);
+
+retry:
+ zio = zio_root(spa, NULL, NULL, flags);
+ vdev_label_write(zio, vd, 0, pad2,
+ offsetof(vdev_label_t, vl_pad2),
+ VDEV_PAD_SIZE, NULL, NULL, flags);
+ error = zio_wait(zio);
+ if (error != 0 !(flags ZIO_FLAG_TRYHARD)) {
+ flags |= ZIO_FLAG_TRYHARD;
+ goto retry;
+ }
+
+ zio_buf_free(pad2, VDEV_PAD_SIZE);
+ return (error);
+}
+
/*
*
==
* uberblock load/sync
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
index e208ed8..ff90839 100644
--- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
@@ -3404,6 +3404,53 @@ zfs_ioc_log_history(const char *unused, nvlist_t
*innvl,
nvlist_t *outnvl)
return (error);
}
+#ifdef __FreeBSD__
+static int
+zfs_ioc_nextboot(const char *unused, nvlist_t *innvl, nvlist_t *outnvl)
+{
+ char name[MAXNAMELEN];
+ spa_t *spa;
+ vdev_t *vd;
+ char *command;
+ uint64_t pool_guid;
+ uint64_t vdev_guid;
+ int error;
+
+ if (nvlist_lookup_uint64(innvl,
+ ZPOOL_CONFIG_POOL_GUID, pool_guid) != 0)
+ return (EINVAL);
+ if (nvlist_lookup_uint64(innvl,
+ ZPOOL_CONFIG_GUID, vdev_guid) != 0)
+ return (EINVAL);
+ if (nvlist_lookup_string(innvl,
+ command, command) != 0)
+ return (EINVAL);
+
+ mutex_enter(spa_namespace_lock);
+ spa = spa_by_guid(pool_guid, vdev_guid);
+ if (spa != NULL)
+ strcpy(name, spa_name(spa));
+ mutex_exit(spa_namespace_lock);
+ if (spa == NULL)
+ return (ENOENT);
+
+ if ((error = spa_open(name, spa, FTAG)) != 0)
+ return (error);
+ spa_vdev_state_enter(spa, SCL_ALL);
+ vd = spa_lookup_by_guid(spa, vdev_guid, B_TRUE);
+ if (vd == NULL) {
+ (void) spa_vdev_state_exit(spa, NULL, ENXIO);
+ spa_close(spa, FTAG);
+ return (ENODEV);
+ }
+ error =
possible selrecord optimization ?
Looking at how selrecord() / selwakeup() and their Linux counterparts poll_wait() and wake_up() are used, i noticed the following: - linux tends to call wake_up() unconditionally at the beginning of the poll handler - FreeBSD tends to call selrecord() only when it detects a blocking situation, and this also requires something (a lock or a retry; the lock in selinfo is not good for this) to avoid the race between the blocking_test..selrecord pair and the selwakeup(). FreeBSD could call selrecord unconditionally (and save the extra lock/retry), but selrecord is expensive as it queues the thread on the struct selinfo, and this takes a lock. I wonder if we could use the same optimization as Linux: as soon as pollscan/selscan detects a non-blocking fd, make selrecord a no-op (which is probably as simple as setting SELTD_RESCAN; and since it only goes up we do not need to lock to check it). This way, we would pay at most for one extra selrecord per poll/select. Even more interesting, it could simplify the logic and locking in poll handlers. As an example, in sys/uipc_socket.c :: sopoll_generic() we could completely decouple the locks on so_snd and so_rcv. comments ? Note that it is only an optimization, so we could write poll handlers in the selrecord-then-test style even without it. cheers luigi ___ 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
