Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW
18.02.2023 18:42, FreeBSD User пишет: On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN interface. We use NPTv6 to translate ULA addresses for the inner IPv6 networks. We use IPv6 privacy on the tun0 interface. The router/firewall is operating after a reboot or restart of mpd5 correctly, IPv6 and IPv4 networks have conection to the internet. When the ISP rotates it IPs, the IPv6 address is configured using SLAAC and mpd5 seems to act weird: - the IPv4 address is always set correct, IPFW and in-kernel NAT route/filter traffic correctly - sometimes old IPv6 address is dumped and only a new IPv6 address - in such a case, the old IPv6 is gone, the new pair (temporary and MACified address are the only IPv6 addresses attached to the interface. - sometimes the old IPv6 address set (= temporary) are marked "deprecated" and/or "detached" and a new set is attached to the interface tun0, in some rare occassion also an IPv6 address WITHOUT its "temoprary" sibbling is attached. In any of the cases above, IPFW's NPTv6 gets confused, routing isn't working properly anymore. In any cases of a change of the IPv6 address, IPFW has to be restartet! Hi, I assume you are using ext_if option in your NPTv6 instance configuration. I think there might be several problems that lead to your situation: 1. NPTv6 tracks IPv6 addresses deletion, but since an old IPv6 address that was used as external prefix kept on the interface, it ignores appearance of new IPv6 address. 2. Then, even if you delete old IPv6 address by hand, NPTv6 won't try to peak another one until there won't appear new address. 3. There should be some logic that takes into account presence of temporary and deprecated addresses on the interface. -- WBR, Andrey V. Elsukov OpenPGP_signature Description: OpenPGP digital signature
Re: system freeze on 14.0-CURRENT
28.03.2021 08:03, Masachika ISHIZUKA пишет: > I have trouble with recent 14.0-CURRENT 146 (e.x. main-6a762cfae, > main-3ead60236, main-25bfa4486). > It works well on recent 14.0-CURRENT until starting firefox. > If I start firefox (v87.0), system freeze but no core dumps. > If it booted old kernel 145 (e.x. main-b5449c92b), firefox v87.0 > is working well. I have successful installed 14.0-CURRENT on the lenovo x1 carbon g8, but it just hangs when I tried to build the kernel. And I'm unable to enter the debugger. I think it happens when CPU load reaches some level. I tried to disable hwpstate_intel via loader.conf and it helps: % grep hint /boot/loader.conf hint.hwpstate_intel.0.disabled="1" My old lenovo x1 carbon gen 4 was hanging on boot with the same symptoms. -- WBR, Andrey V. Elsukov OpenPGP_signature Description: OpenPGP digital signature
Re: kernel panic and fun debugging
On 15.10.2020 09:56, Steve Kargl wrote: > Just had a kernel panic. Best info I give you is > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r366176M: Sat Sep 26 > 10:35:23 PDT 2020 kargl@mobile:/usr/obj/usr/src/i386.i386/sys/MOBILE i386 > > % kgdb gdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.1 > ... > Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug... > /usr/ports/devel/gdb/work-py37/gdb-9.2/gdb/inferior.c:283: internal-error: > struct inferior *find_inferior_pid(int): Assertion `pid != 0' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. Hi, do you have /var/crash/core.txt.1 file? It may have some useful info. Also did you try an old version /usr/libexec/kgdb ? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: hwpstate_intel hangs kernel
31.01.2020 18:11, Andrey V. Elsukov пишет: > On 24.01.2020 19:52, Andreas Nilsson wrote: >> It hangs during kernel boot and the last message printed on console is: >> hwpstate_intel0: on cpu0 > > Hi, > > Did you find the cause of this hang? > I also tried to update today from r350816 to r357330. But my Lenovo X1 > Carbon 4th hangs on the same message. > Hi, I have bisected the bad commit, it is r357002. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: hwpstate_intel hangs kernel
On 24.01.2020 19:52, Andreas Nilsson wrote: > It hangs during kernel boot and the last message printed on console is: > hwpstate_intel0: on cpu0 Hi, Did you find the cause of this hang? I also tried to update today from r350816 to r357330. But my Lenovo X1 Carbon 4th hangs on the same message. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panic... r350849M panic: ng_snd_item: 42 != 1414
On 20.08.2019 16:26, Larry Rosenman wrote: > the M is a patch from rrs@ for the previous crash on m_pullup. > > Ideas? I have a core. > > > Unread portion of the kernel message buffer: > panic: ng_snd_item: 42 != 1414 I think you had the same panic about a month ago. Probably it is time to fill the PR. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ng_snd_item: Panic?
On 25.06.2019 15:59, Larry Rosenman wrote:
> On 06/25/2019 4:18 am, Andrey V. Elsukov wrote:
>> On 24.06.2019 23:10, Larry Rosenman wrote:
>>>>> #5 0x828ee5b7 in ng_snd_item (item=0xf8021e3b4d80,
>>>>> flags=0)
>>>>> at /usr/src/sys/netgraph/ng_base.c:2252
>>>>
>>>> It looks like you use some netgraph based ethernet interface.
>>>> The system got received ARP request and is going to send the reply,
>>>> but somehow mbuf with this ARP request has initialized m_next pointer,
>>>> thus it is considered as a chain of mbufs.
>>>>
>>>> in_arpinput() reuses received mbuf to construct the reply, but it
>>>> doesn't check that an mbut is a chain. It just sets m_len and sends it.
>>>> Then since you have INVARIANTS in your kernel, the netgraph code check
>>>> the actual length of the chain, and it doesn't match to m_len. It
>>>> panics.
>>>
>>>
>>> so, is this a bug? Timing race? Other?
>>
>> I think we should determine that my assumption is correct :)
>> Can you show the output of the following commands from the kgdb for this
>> core?
>>
>> (kgdb) f 7
>> (kgdb) p *m
>> (kgdb) p *m->m_next
>
>
> (kgdb) fr 7
> #7 0x805b1e43 in ether_output (ifp=,
> m=0xf81f59eefb00, dst=0xfe012628d740, ro=) at
> /usr/src/sys/net/if_ethersubr.c:430
> 430 if ((error = (*ng_ether_output_p)(ifp, )) != 0) {
I failed to track the possible way to get this.
Please, show the output of the following commands:
(kgdb) f 7
(kgdb) p/x (u_char[42])m->m_data
(kgdb) p/x (u_char[1372]m->m_next->m_data
Did you used this configuration for the long time and these panics were
the first time?
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: ng_snd_item: Panic?
On 24.06.2019 23:10, Larry Rosenman wrote: >>> #5 0x828ee5b7 in ng_snd_item (item=0xf8021e3b4d80, flags=0) >>> at /usr/src/sys/netgraph/ng_base.c:2252 >> >> It looks like you use some netgraph based ethernet interface. >> The system got received ARP request and is going to send the reply, >> but somehow mbuf with this ARP request has initialized m_next pointer, >> thus it is considered as a chain of mbufs. >> >> in_arpinput() reuses received mbuf to construct the reply, but it >> doesn't check that an mbut is a chain. It just sets m_len and sends it. >> Then since you have INVARIANTS in your kernel, the netgraph code check >> the actual length of the chain, and it doesn't match to m_len. It panics. > > > so, is this a bug? Timing race? Other? I think we should determine that my assumption is correct :) Can you show the output of the following commands from the kgdb for this core? (kgdb) f 7 (kgdb) p *m (kgdb) p *m->m_next -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ng_snd_item: Panic?
24.06.2019 21:32, Larry Rosenman пишет: > Got 2 of these today, and I have cores > Ideas? > r349200. > > Unread portion of the kernel message buffer: > panic: ng_snd_item: 42 != 1414 > cpuid = 10 > time = 1561382494 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe012628d400 > vpanic() at vpanic+0x19d/frame 0xfe012628d450 > panic() at panic+0x43/frame 0xfe012628d4b0 > ng_snd_item() at ng_snd_item+0x477/frame 0xfe012628d4f0 > ng_ether_output() at ng_ether_output+0x5e/frame 0xfe012628d520 > ether_output() at ether_output+0x473/frame 0xfe012628d5c0 > arpintr() at arpintr+0xfe3/frame 0xfe012628d780 > netisr_dispatch_src() at netisr_dispatch_src+0x89/frame 0xfe012628d7f0 > ether_demux() at ether_demux+0x137/frame 0xfe012628d820 > ng_ether_rcv_upper() at ng_ether_rcv_upper+0x95/frame 0xfe012628d840 > ng_apply_item() at ng_apply_item+0xf1/frame 0xfe012628d8c0 > ng_snd_item() at ng_snd_item+0x2ab/frame 0xfe012628d900 > ng_apply_item() at ng_apply_item+0xf1/frame 0xfe012628d980 > ng_snd_item() at ng_snd_item+0x2ab/frame 0xfe012628d9c0 > ng_ether_input() at ng_ether_input+0x4c/frame 0xfe012628d9f0 > ether_nh_input() at ether_nh_input+0x2cd/frame 0xfe012628da40 > netisr_dispatch_src() at netisr_dispatch_src+0x89/frame 0xfe012628dab0 > ether_input() at ether_input+0x48/frame 0xfe012628dad0 > bce_intr() at bce_intr+0x697/frame 0xfe012628db50 > ithread_loop() at ithread_loop+0x187/frame 0xfe012628dbb0 > fork_exit() at fork_exit+0x84/frame 0xfe012628dbf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe012628dbf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > Uptime: 4d18h45m34s > Dumping 24921 out of 131026 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > #5 0x828ee5b7 in ng_snd_item (item=0xf8021e3b4d80, flags=0) > at /usr/src/sys/netgraph/ng_base.c:2252 It looks like you use some netgraph based ethernet interface. The system got received ARP request and is going to send the reply, but somehow mbuf with this ARP request has initialized m_next pointer, thus it is considered as a chain of mbufs. in_arpinput() reuses received mbuf to construct the reply, but it doesn't check that an mbut is a chain. It just sets m_len and sends it. Then since you have INVARIANTS in your kernel, the netgraph code check the actual length of the chain, and it doesn't match to m_len. It panics. > #6 0x82900c2e in ng_ether_output (ifp=, > mp=0xfe012628d578) at /usr/src/sys/netgraph/ng_ether.c:294 > #7 0x805b1e43 in ether_output (ifp=, > m=0xf81f59eefb00, dst=0xfe012628d740, ro=) > at /usr/src/sys/net/if_ethersubr.c:430 > #8 0x805cb3e3 in in_arpinput (m=) > at /usr/src/sys/netinet/if_ether.c:1152 > #9 arpintr (m=0xf81f59eefb00) at /usr/src/sys/netinet/if_ether.c:749 > #10 0x805bcf89 in netisr_dispatch_src (proto=4, > source=, m=) at /usr/src/sys/net/netisr.c:1123 > #11 0x805b22d7 in ether_demux (ifp=0xf8012c902000, > m=) at /usr/src/sys/net/if_ethersubr.c:913 > #12 0x82901045 in ng_ether_rcv_upper (hook=, > item=) at /usr/src/sys/netgraph/ng_ether.c:741 > #13 0x828ee6e1 in ng_apply_item (node=0xf81054f43400, > item=0xf8021e3b4d80, rw=0) at /usr/src/sys/netgraph/ng_base.c:2403 > #14 0x828ee3eb in ng_snd_item (item=0xf8021e3b4d80, flags=0) > at /usr/src/sys/netgraph/ng_base.c:2320 > #15 0x828ee6e1 in ng_apply_item (node=0xf8012c2d3e00, > item=0xf8021e3b4d80, rw=0) at /usr/src/sys/netgraph/ng_base.c:2403 > #16 0x828ee3eb in ng_snd_item (item=0xf8021e3b4d80, flags=0) > at /usr/src/sys/netgraph/ng_base.c:2320 > #17 0x82900cbc in ng_ether_input (ifp=, > mp=0xfe012628da18) at /usr/src/sys/netgraph/ng_ether.c:255 > #18 0x805b34fd in ether_input_internal (ifp=0xf8012c902000, > m=0xf81f59eefb00) at /usr/src/sys/net/if_ethersubr.c:654 > #19 ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:735 > #20 0x805bcf89 in netisr_dispatch_src (proto=5, > source=, m=) at /usr/src/sys/net/netisr.c:1123 > #21 0x805b26f8 in ether_input (ifp=0xf8012c902000, m=0x0) > at /usr/src/sys/net/if_ethersubr.c:823 > #22 0x8273c7f7 in bce_rx_intr (sc=) > at /usr/src/sys/dev/bce/if_bce.c:6848 > #23 bce_intr (xsc=0xfe01665c2000) at /usr/src/sys/dev/bce/if_bce.c:8017 > #24 0x8047e0e7 in intr_event_execute_handlers (p=, > ie=) at /usr/src/sys/kern/kern_intr.c:1148 > #25 ithread_execute_handlers (p=, ie=) > at /usr/src/sys/kern/kern_intr.c:1161 > #26 ithread_loop (arg=) at /usr/src/sys/kern/kern_intr.c:1241 &
random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.
Hi, today I updated one of my test machines and discovered that message from the subject periodically printed in the console. FreeBSD 13.0-CURRENT r347327=4f47587(svn_head) GENERIC-NODEBUG amd64 FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) VT(vga): resolution 640x480 CPU: Intel(R) Xeon(R) CPU E5-2660 v4@ 2.00GHz (2000.04-MHz K8-class CPU) ... real memory = 68719476736 (65536 MB) avail memory = 66722340864 (63631 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 28 CPUs FreeBSD/SMP: 2 package(s) x 14 core(s) ... % grep -c random /var/run/dmesg.boot 606 % grep random /var/run/dmesg.boot | head -10 __stack_chk_init: WARNING: Initializing stack protection with non-random cookies! random: entropy device external interface random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy. % sysctl -a | grep -v random_sources_feed | grep rand kern.fallback_elf_brand: -1 device random device rdrand_rng kern.randompid: 0 kern.elf32.fallback_brand: -1 kern.elf64.fallback_brand: -1 kern.random.fortuna.minpoolsize: 64 kern.random.harvest.mask_symbolic: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED kern.random.harvest.mask_bin: 000100011101 kern.random.harvest.mask: 66015 kern.random.use_chacha20_cipher: 0 kern.random.block_seeded_status: 0 kern.random.random_sources: 'Intel Secure Key RNG' kern.random.initial_seeding.disable_bypass_warnings: 0 kern.random.initial_seeding.arc4random_bypassed_before_seeding: 1 kern.random.initial_seeding.read_random_bypassed_before_seeding: 0 kern.random.initial_seeding.bypass_before_seeding: 1 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.random_id_total: 0 net.inet.ip.random_id_collisions: 0 net.inet.ip.random_id_period: 0 net.inet.ip.random_id: 0 net.key.int_random: 60 debug.fail_point.status_fill_kinfo_vnode__random_path: off debug.fail_point.fill_kinfo_vnode__random_path: off debug.fail_point.status_random_fortuna_pre_read: off debug.fail_point.random_fortuna_pre_read: off security.stack_protect.permit_nonrandom_cookies: 1 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: icmp (IPv4) issues with VIMAGE JAILs and IPv6
On 28.01.2019 15:44, O. Hartmann wrote:
> Stopping all jails, destroying all epairs and bridge0 doesn't change anything.
> The problems occured when IPv6 came into play on the specific host in
> question.
>
> Does anyone have any ideas? I'm out of ideas.
Hi,
I think I found the problem, the bug was introduced in r342908.
Can you try attached patch?
--
WBR, Andrey V. Elsukov
Index: sys/netpfil/ipfw/ip_fw2.c
===
--- sys/netpfil/ipfw/ip_fw2.c (revision 343395)
+++ sys/netpfil/ipfw/ip_fw2.c (working copy)
@@ -1410,6 +1410,7 @@ ipfw_chk(struct ip_fw_args *args)
dst_ip.s_addr = 0; /* make sure it is initialized */
src_ip.s_addr = 0; /* make sure it is initialized */
+ src_port = dst_port = 0;
pktlen = m->m_pkthdr.len;
DYN_INFO_INIT(_info);
@@ -1688,7 +1689,6 @@ do {\
args->f_id.dst_ip = ntohl(dst_ip.s_addr);
} else {
proto = 0;
- src_port = dst_port = 0;
dst_ip.s_addr = src_ip.s_addr = 0;
args->f_id.addr_type = 1; /* XXX */
signature.asc
Description: OpenPGP digital signature
Re: icmp (IPv4) issues with VIMAGE JAILs and IPv6
On 28.01.2019 15:44, O. Hartmann wrote: > Stopping all jails, destroying all epairs and bridge0 doesn't change anything. > > The problems occured when IPv6 came into play on the specific host in > question. > > Does anyone have any ideas? I'm out of ideas. Since your ruleset is relatively simple, first of try to use "log" opcode for "deny" rules and look what happens in the /var/log/security. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled
On 20.01.2019 21:09, David Boyd wrote: > 13.0-CURRENT drops to debugger on shutdown with IPNAT enabled. > > Running in VirtualBox 6.0.2. > > The identical configuration running 12.0-RELEASE-p2, 12.0-STABLE, 11.2- > RELEASE-p8 and 11.2-STABLE do not exhibit this behavior. > > This (VM) is a test machine and I can do anything that will help > identify the root of this problem. > > I have included screenshots of the debug output and a backtrace. Hi, mail list strips non-text attachments, you need to create bug report in bugzilla or use some external hosting for screenshots. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: netipsec/key.c ALPHA3 uma_zalloc->witness_warn, exclusive sleep mutex xforms_list (IPsec transforms list)
On 24.09.2018 11:31, Harry Schmalzbauer wrote: > Hello, > > unfortunately this is far beyond my scope and I forgot to report in time. > If this is begnin, feel free to ignore, but in any case I'd appreciate > any comments. Hi, I posted a review targeted to fix this problem: https://reviews.freebsd.org/D17302 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: udp6: Page fault panics
On 16.09.2018 03:04, Larry Rosenman wrote:
> vpanic() at vpanic+0x1a3/frame 0xfe00ca17c150
> panic() at panic+0x43/frame 0xfe00ca17c1b0
> trap_fatal() at trap_fatal+0x35f/frame 0xfe00ca17c200
> trap_pfault() at trap_pfault+0x49/frame 0xfe00ca17c260
> trap() at trap+0x2ba/frame 0xfe00ca17c370
> calltrap() at calltrap+0x8/frame 0xfe00ca17c370
> --- trap 0xc, rip = 0x80631428, rsp = 0xfe00ca17c440, rbp =
> 0xfe00ca17c480 ---
> selectroute() at selectroute+0x198/frame 0xfe00ca17c480
> in6_selectroute_fib() at in6_selectroute_fib+0xf/frame 0xfe00ca17c4a0
> ip6_output() at ip6_output+0xfd7/frame 0xfe00ca17c710
(kgdb) l *selectroute+0x198
0x80de14c8 is in selectroute
(/home/devel/freebsd/base/head/sys/netinet6/in6_src.c:736).
731 * Use a cached route if it exists and is valid, else try to
allocate
732 * a new one. Note that we should check the address family of
the
733 * cached destination, in case of sharing the cache with IPv4.
734 */
735 if (ro) {
736 if (ro->ro_rt &&
737 (!(ro->ro_rt->rt_flags & RTF_UP) ||
738 ((struct sockaddr *)(>ro_dst))->sa_family !=
AF_INET6 ||
739
!IN6_ARE_ADDR_EQUAL((>ro_dst)->sin6_addr,
740 dst))) {
> calltrap() at calltrap+0x8/frame 0xfe00c9d863e0
> --- trap 0xc, rip = 0x80636b2b, rsp = 0xfe00c9d864b0, rbp =
> 0xfe00c9d86710 ---
> ip6_output() at ip6_output+0xeeb/frame 0xfe00c9d86710
> udp6_send() at udp6_send+0x720/frame 0xfe00c9d868d0
(kgdb) l *ip6_output+0xeeb
0x80de75bb is in ip6_output
(/home/devel/freebsd/base/head/sys/netinet6/ip6_output.c:531).
526 */
527 if (inp) {
528 ro->ro_dst.sin6_family = AF_INET6;
529 RT_VALIDATE((struct route *)ro, >inp_rt_cookie,
fibnum);
530 }
531 if (ro->ro_rt && fwd_tag == NULL && (ro->ro_rt->rt_flags &
RTF_UP) &&
532 ro->ro_dst.sin6_family == AF_INET6 &&
533 IN6_ARE_ADDR_EQUAL(>ro_dst.sin6_addr, >ip6_dst)) {
534 rt = ro->ro_rt;
535 ifp = ro->ro_rt->rt_ifp;
It looks like Ryan's assumption is correct and panics happen due to
several threads use the same PCB and then route cache invalidation happens.
https://lists.freebsd.org/pipermail/freebsd-net/2018-September/051563.html
But IPv6 path also needs similar patch.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: gif does not work when going over IPv6 on current
On 15.08.2018 23:47, Lars Schotte wrote: > Hey folks, > > when you create a gif with IPv6 tunnel endpoints > tcpdump on the underlying interface will show you some kind of error > that 0 != 6 and packets will be dropped. > > IP6 version error: 0 != 6 > repeating for each packet. > happens only while sending. receiving works. > > This happens only on 12-current as I am aware, 11-stable works good. > I worked around this issue by setting IPv4 tunnel endpoints. Hi, should be fixed in r337900. Thanks for the report. And sorry for breakage. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716
On 11.04.2018 20:02, Mark Johnston wrote: >> It appears that r332389 is implicated. > > I'm seeing this too, under bhyve with e1000 emulation. Reverting r332389 > fixes the problem. I have this problem too. And reverting r332389 fixes it. em0@pci0:0:25:0:class=0x02 card=0x20088086 chip=0x15028086 rev=0x04 hdr=0x00 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panic on boot after SVN r328988
On 16.02.2018 17:44, Michael Butler wrote: >> do you have some specific optimization flags in make.conf? >> Can you show the output of `head -40 /var/run/dmesg.boot`? >> > > The only relevant flags in /etc/make.conf are .. > > CPUTYPE?=pentium3 > KERNCONF=SARAH > NO_MODULES=YES > > Boot log from last night's failure attached, Ok, it seems ConcurrencyKit was not tested with Pintium3. Can you show the output from kgdb: disassemble *0xc0991ff0 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panic on boot after SVN r328988
On 16.02.2018 17:13, Michael Butler wrote: > ipfw is compiled into the kernel not loaded as a module. Hi, do you have some specific optimization flags in make.conf? Can you show the output of `head -40 /var/run/dmesg.boot`? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipfw: manpage: semantics of "receive" and "xmit" interfaces
On 09.01.2018 12:28, O. Hartmann wrote: > In section RULE OPTIONS, there is recv|xmit|via explained (a bit). There is > also an example: > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > Can someone explain a bit more what the semantics of these is? I get > especially > confused by the subsequent blocks of text following the line I mentioned > above. > Since not everybody using FreeBSD is capable of studying the kernel sources, I > have difficulties to put those statements in line with a visualization of the > packet flow. A local host receiving a packets destined for the local host can > not have xmit interface? If I imagine, that the recv interface might be the > interface adjacent directly to the in/out port depicted in section PACKET FLOW > it doesn't give me any idea why there is no xmit interface. When your system has two interfaces ed0 and ed1, and it acts as router, a forwarded packet can be checked by firewall two times: 1. When a packet is received on ed0 interface, mbuf associated with this packet gets a property "receiving interface". This packet is checked for inbound direction and can be matched by "in" and "recv ed0" opcodes. If it was not dropped by rules, it will go through IP stack and can be forwarded according to routing table via interface ed1. 2. When the routing decision was made (i.e. outbound interface is determined) a packet checked by firewall again, now for outbound direction. And it can be matched by "out" and "xmit ed1" opcodes. The opcode "recv ed0" still can be matched too, but "in" opcode will not matched. A packet destined for local host is consumed by local IP stack and will not forwarded. It is checked by firewall only one time (usually). Thus it can not have xmit interface. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: r323412: Panic on boot (slab->us_keg == keg)
On 12.09.2017 06:35, Mark Johnston wrote: >> [...] >> FreeBSD/SMP: 2 package(s) x 14 core(s) x 2 hardware threads >> >> Also I determined that it can successfully boot with disabled >> hyper-threading. > > After the change to CACHE_LINE_SIZE, we have > sizeof(struct uma_zone) == 448 and sizeof(struct uma_cache) == 64. With > 56 CPUs, we therefore need 4032 bytes per UMA zone, plus 80 bytes for > the slab header - "internal" zones always keep the slab header in the > slab itself. That's slightly larger than one page, but the UMA zone > zone's keg will have uk_ppera == 1. So, when allocating slabzone, > keg_alloc_slab() will call startup_alloc(uk_ppera * PAGE_SIZE), which > will allocate 4096 bytes for a structure that is 4032 + 80 = 4112 bytes > in size. > > I think the bug is that keg_large_init() doesn't take > sizeof(struct uma_slab) into account when setting uk_ppera for the keg. > In particular, the bug isn't specific to the bootup process; it only > affects internal zones with an item size in the range [4016, 4096]. > > The patch below should fix this - could you give it a try? Hi Mark, I can confirm that it fixes this panic. Thanks! -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: r323412: Panic on boot (slab->us_keg == keg)
On 11.09.2017 21:38, John Baldwin wrote: > On Monday, September 11, 2017 09:15:51 PM Andrey V. Elsukov wrote: >> On 11.09.2017 15:23, Andrey V. Elsukov wrote: >>> --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = >>> 0x821939b0 --- >>> zone_import() at zone_import+0x110/frame 0x821939b0 >>> zone_alloc_item() at zone_alloc_item+0x36/frame 0x821939f0 >>> uma_startup() at uma_startup+0x1d0/frame 0x82193ae0 >>> vm_page_startup() at vm_page_startup+0x34e/frame 0x82193b30 >>> vm_mem_init() at vm_mem_init+0x1a/frame 0x82193b50 >>> mi_startup() at mi_startup+0x9c/frame 0x82193b70 >>> btext() at btext+0x2c >>> Uptime: 1s >> >> I bisected revisions, and the last working is r322988. >> This machine is E5-2660 v4@ based. > > If you just revert r322988 on a newer tree does it work ok? r322988 works, reverting r322989 (commit about CACHELINE) does help. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: r323412: Panic on boot (slab->us_keg == keg)
On 11.09.2017 15:23, Andrey V. Elsukov wrote: > --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = > 0x821939b0 --- > zone_import() at zone_import+0x110/frame 0x821939b0 > zone_alloc_item() at zone_alloc_item+0x36/frame 0x821939f0 > uma_startup() at uma_startup+0x1d0/frame 0x82193ae0 > vm_page_startup() at vm_page_startup+0x34e/frame 0x82193b30 > vm_mem_init() at vm_mem_init+0x1a/frame 0x82193b50 > mi_startup() at mi_startup+0x9c/frame 0x82193b70 > btext() at btext+0x2c > Uptime: 1s I bisected revisions, and the last working is r322988. This machine is E5-2660 v4@ based. CPU: Intel(R) Xeon(R) CPU E5-2660 v4@ 2.00GHz (2000.04-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 Features=0xbfebfbff<FPU,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=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> AMD Features2=0x121<LAHF,ABM,Prefetch> Structured Extended Features=0x21cbfbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE> XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 66562076672 (63478 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 56 CPUs FreeBSD/SMP: 2 package(s) x 14 core(s) x 2 hardware threads Also I determined that it can successfully boot with disabled hyper-threading. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: r323412: Panic on boot (slab->us_keg == keg)
On 11.09.2017 11:31, Raphael Kubo da Costa wrote: > I've recently tried to upgrade a HEAD VM (running on a Linux host with > QEMU) from r321082 to r323412. > > The new kernel panics right after I try to boot into it with: > > panic: Assertion slab->us_keg == keg failed at /usr/src/sys/vm/uma_core.c:2285 > cpuid = 0 > time = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x81c4d780 > vpanic() at vpanic+0x19c/frame 0x81c4d800 > kassert_panic() at kassert_panic+0x126/frame 0x81c4d870 > keg_fetch_slab() at keg_fetch_slab+0x2a9/frame 0x81c4d8c0 > zone_fetch_slab() at zone_fetch_slab+0x51/frame 0x81c4d8f0 > zone_import() at zone_import+0x4f/frame 0x81c4d960 > zone_alloc_item() at zone_alloc_item+0x36/frame 0x81c4d9a0 > uma_zcreate() at uma_zcreate+0x3d3/frame 0x81c4da40 > uma_startup() at uma_startup+0x147/frame 0x81c4dae0 > vm_page_startup() at vm_page_startup+0x34e/frame 0x81c4db30 > vm_mem_init() at vm_mem_init+0x1a/frame 0x81c4db50 > mi_startup() at mi_startup+0x9c/frame 0x81c4db70 > btext() at btext+0x2c > KDB: enter: panic > [ thread 0 pid 0 tid 0 ] I have r323177 based system without INVARIANTS that panics at netboot with similar trace: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x84 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80d84870 stack pointer = 0x28:0x82193970 frame pointer = 0x28:0x821939b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 0 () trap number = 12 panic: page fault cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x82193550 vpanic() at vpanic+0x19c/frame 0x821935d0 panic() at panic+0x43/frame 0x82193630 trap_fatal() at trap_fatal+0x34d/frame 0x82193680 trap_pfault() at trap_pfault+0x49/frame 0x821936e0 trap() at trap+0x2a9/frame 0x821938a0 calltrap() at calltrap+0x8/frame 0x821938a0 --- trap 0xc, rip = 0x80d84870, rsp = 0x82193970, rbp = 0x821939b0 --- zone_import() at zone_import+0x110/frame 0x821939b0 zone_alloc_item() at zone_alloc_item+0x36/frame 0x821939f0 uma_startup() at uma_startup+0x1d0/frame 0x82193ae0 vm_page_startup() at vm_page_startup+0x34e/frame 0x82193b30 vm_mem_init() at vm_mem_init+0x1a/frame 0x82193b50 mi_startup() at mi_startup+0x9c/frame 0xffff82193b70 btext() at btext+0x2c Uptime: 1s -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Inter-VLAN routing on CURRENT: any known issues?
On 14.07.2017 14:42, O. Hartmann wrote: > I use in-kernel NAT. IPFW is performing NAT. In firewall type "OPEN" from the > vanilla rc.conf, IPFW has instance "nat 123" which provides then NAT. I never used default config types for firewall, so, it would be nice to see what rules do you have. # ipfw show # ipfw nat show config >> VLANs work on the layer2 > According to 1): > > I consider the settings of the switch now as correct. I have no access to the > router right now. But I did short experiments yesterday evening and it is > weird: loged in on thr router, I can ping every host on any VLAN, so ICMP > travel from the router the right way to its destination and back. > > From any host on any VLAN that is "trunked" through the router, I can ping any > other host on any other VLAN, preferrably not on the same VLAN. By cutting off > the trunk line to the router, pinging stops immediately. > > From any host on any VLAN I can ping any host which is NATed on the outside > world. > > From the router itself, I can ssh into any host on any VLAN providing ssh > service. That said, according to question 3), NAT is considered to be setup > correctly. > > Now the strange things: Neither UDP, nor TCP services "flow" from hosts on one > VLAN to hosts on a different VLAN. Even ssh doens't work. > When loged in onto the router, I can't "traceroute" any host on any VLAN. This is most likely due to the problem with firewall rules. If you set net.inet.ip.firewall.enable=0, does it solve the problem with TCP/UDP between hosts on a different VLANs? > According to question 2), the ability to ping from, say, a host on VLAN 1000 > to > another host on VLAN 2 passing through the router would indicate that both > sides know their routes to each other. Or am I wrong? Yes. > I got words from Sean bruno that there might be a problem with the Intel i210 > chipset in recent CURRENT - and the hardware on the PCEngine APU 2C4 is three > i210. I'm aware of the problem since r320134 (the oldest CURRENT I started > experimenting with the VLAN trunking). It is very strange problems, why ICMP works, but TCP/UDP does not? :) You can try to disable any type of offloading for the card, there were some problems in the past with checksum offlading, that may lead to the problems with TCP, but this usually should be noticeable in the tcpdump output. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Inter-VLAN routing on CURRENT: any known issues?
On 12.07.2017 22:43, O. Hartmann wrote: > Now the FUN PART: > > From any host in any VLAN I'm able to ping hosts on the wild internet via > their IP, on > VLAN 1000 there is a DNS running, so I'm also able to resolv names like > google.com or > FreeBSD.org. But I can NOT(!) access any host via http/www or ssh. You have not specified where is the NAT configured and its settings is matters. VLANs work on the layer2, they do not used for IP routing. Each received packet loses its layer2 header before it gets taken by IP stack. If an IP packet should be routed, the IP stack determines outgoing interface and new ethernet header with VLAN header from this interface is prepended. What I would do in your place: 1. Check the correctness of the switch settings. - on the router use tcpdump on each vlan interface and also directly on igb1. Use -e argument to see ethernet header. Try ping router's IP address from each vlan, you should see tagged packet on igb1 and untagged on corresponding vlan interface. 2. Check the correctness of the routing settings for each used node. - to be able establish connection from one vlan to another, both nodes must have a route to each other. 3. Check the NAT settings. - to be able to connect to the Internet from your addresses, you must use NAT. If you don't have NAT, but it somehow works, this means that some device does the translation for you, but it's configuration does not meet to your requirements. And probably you need to translate prefixes configured for your vlans independently. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panics in network stack in 12-current
On 27.04.2017 08:42, Tom Uffner wrote: > Tom Uffner wrote: >> Andrey V. Elsukov wrote: >>> I think the most of these panics should be fixed in r315956. >> >> thanks. I'll give it a try and report back as soon as I have a result. > > r315956 panicked about 22 min after boot. failed to dump a core. Why not update to the latest revision? Probably this is flowtable related, don't think it is usable. Anyway we need the trace to determine the cause. Also it seems you have VIMAGE enabled. This also have some known panics. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panics in network stack in 12-current
On 26.04.2017 04:03, Tom Uffner wrote: > Since updating my -current box to 12 several months ago, I have been > trying to pin down several elusive and probably related panics. > > they always manifest a a trap out of rw_wlock_hard() > > i am fairly certain that r302409 was stable, revs up through r306792 may be > stable, or perhaps I just didn't wait long enough for my system to panic. I > don't know of anything that I can reproducably poke at to trigger this. > r306807 is definitely bad, as is everything up through r309124. I > haven't seen anything on the mailing lists or in the SVN logs that looks > like it is related to my problem. > > my hardware is an Asus M4A77TD MB, AMD Phenom 2 X6 1100T CPU (for some of > this time I had an Athlon 2 X2, but upgraded recently), and RealTek 8168 > PCIe Gigabit NIC. > > FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #33 > r306807M: Tue Apr 18 17:09:55 EDT 2017 > t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 > > in revs between 306807-307125, the panics have been in flowcleaner, in > more recent ones, they happen in arbitrary userspace processes that make > heavy use > of the network. > > I know I should try the latest rev to see if it went away. aside from > that, any thoughts on how I should proceed? I think the most of these panics should be fixed in r315956. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: GEOM has amnesia
On 01.04.2017 00:58, Chris H wrote:
> So. I spin up an old 11 server I have sitting in the closet, with
> this external drive attached to it. I do *NOT* get the corrupt GPT
> message. So I blank/partition/newfs the external drive &&
> mount the partitions individually to /mnt && restore again. When I
> reboot to the external drive still connected to the old 11 server,
> I do *NOT* receive the corrupt GPT message. WooHoo! I think.
> So I re-attach the drive to the new 12 server. Reboot, and can't
> boot to it && get the corrupt GPT message.
>
> GEOM seems to be broken in 12, maybe even (recent) 11. As the 11
> server I used for testing is ~9 mos out.
>
> What can I do to (help?) fix this mess?
Just a guess, BIOS on the system, where FreeBSD 12 is installed
overwrites the last sector of your disks.
I have seen such reports, and always this was the cause.
You can do the following steps to make sure:
* on the old 11 system with the sane GPT save the last sector to some file.
* reboot, save the sector again to another file and compare both files.
* attach the disk to your 12 system, GPT should become corrupted. Save
the last sector and compare with previous file.
You can look at the hexdump of this file, and probably it should be
obviously what is extraneous in the data.
To save the last sector you need to know its number, it can be found by
this command:
# diskinfo da0 | awk '{print $4-1}'
Then use dd to save it:
# dd if=/dev/da0 of=./sector skip=`diskinfo da0 | awk '{print $4-1}'`
# hexdump -C ./sector
You should see something like this:
45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI
PART\...|
0010 d7 b2 b7 bc 00 00 00 00 af 32 cf 1d 00 00 00 00
|.2..|
0020 01 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00
|(...|
0030 87 32 cf 1d 00 00 00 00 a0 4a 4a e0 b0 0a e7 11
|.2...JJ.|
0040 ba c4 54 ee 75 ad 8c c7 8f 32 cf 1d 00 00 00 00
|..T.u2..|
0050 80 00 00 00 80 00 00 00 22 88 eb 6d 00 00 00 00
|"..m|
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
||
*
0200
The dump of correct GPT header should not have more lines.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: [RFC/RFT] projects/ipsec
On 06.02.2017 16:27, peter.b...@bsd4all.org wrote: Andrey, Is this going to MFC'ed to stable-11 in the future? I have tested with current and found no issues, but I would like to add it to a semi-production environment running stable-11 Hi, I thought to make MFC after a month or two, but I didn't seen any information when 11.1-RELEASE is planned. So, I don't know when feature freeze begins. Also there are some changes that can be considered as POLA violation, especially the single name space for SPI can affect some users. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On 11.12.2016 02:07, Andrey V. Elsukov wrote: I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in SADB/SPDB faster; * revise PFKEY implementation, remove stale code, make it closer to RFC; * implement IPsec VTI (virtual tunneling interface); * make IPsec code loadable as kernel module. JFYI, the project was merged into head/ in r313330. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
Hi All, I ported the changes from projects/ipsec to stable/11 branch. So, if it is more suitable for testing, please, welcome. You can checkout the sources from github: https://github.com/bu7cher/freebsd/tree/stable/11 Also I made the standalone patch: https://people.freebsd.org/~ae/ipsec.diff Unfortunately, I did only compile test for stable branch. I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in SADB/SPDB faster; * revise PFKEY implementation, remove stale code, make it closer to RFC; * implement IPsec VTI (virtual tunneling interface); * make IPsec code loadable as kernel module. Currently all, except the last one is mostly done. So, I decided ask for a help to test the what already done, while I will work on the last task. How to try? There are no patches, you need to checkout the full projects/ipsec source tree, and build the kernel and the base system. There are very few changes in the base system, mostly the kernel changes. Thus for testing that old configuration is still work, it is enough to build only the kernel. The approximate list of changes that may be visible to users: * SA bundles now can have only 4 items in the chain. I think it is enough, I can't imagine configurations when needed more. Also now SA bundles supported for IPv6 too. * due to changes in SPDB/SADB, systems where large number of SPs and SAs are in use should get significant performance benefits. * the memory consumption should slightly increase. There are several hash tables and SP cache appeared. * INPCB SP cache should noticeable increase network performance of application when security policies are presence. https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html * use transport mode IPsec for forwarded IPv4 packets now unsupported. This matches the IPv6 behavior, and since we can handle the replies, I think it is useless. * Added net.inet.ipsec.check_policy_history sysctl variable. When it is set, each inbound packet that was handled by IPsec will be checked according to matching security policy. If not all IPsec transforms were applied, the check will fail, and packet will be dropped. * Many PF_KEY messages handlers was updated, probably some IKEd now may fail due to stricter checks. * SPI now unique for each SA. This also can break something. * Added if_ipsec interface. For more info look at https://svnweb.freebsd.org/base?view=revision=309115 https://reviews.freebsd.org/P112 * TCP_SIGNATURE code was reworked and now it behaves closer to RFC https://svnweb.freebsd.org/base?view=revision=309610 * NAT-T support was reworked. https://svnweb.freebsd.org/base?view=revision=309808 Also I made the patch to racoon that adds better support of NAT-T, you can use this port to build patched racoon: https://people.freebsd.org/~ae/ipsec-tools.tgz What results is interesting to me? If you have some nontrivial configuration, please test. If you have some configuration, that did't work, please test this branch. If you have performance problems, please test. But don't forget that this is head/ branch, you need to disable all debugging first. If you just want to test, pay attention to the output of `vmstat -m | egrep "sec|sah|pol|crypt"`. If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this support was significantly changed. IPsec as kernel modules was reported here: https://lists.freebsd.org/pipermail/freebsd-net/2016-December/046762.html Some additional testing also needed with this... -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On 09.01.2017 14:38, Bjoern A. Zeeb wrote: On 27 Dec 2016, at 10:18, Andrey V. Elsukov wrote: So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. I still keep seeing almost daily changes to the branch and am having a hard time to convince myself to do a proper review that way. I would very much prefer this to be (a) either become stable first and then give people a chance, or (b) see if you can break out small self-contained changes put them up into review and merge them piece by piece making it a lot easier to convince ourselves that things still look good. Hi, yes, I hope I have fixed all found issues, now I will test the changes in our environment. I prefer the first way (a), because another splitting into small pieces requires a lot of time that I don't have. So, if you want to do a review, you are welcome :) Now I'll be focused on testing with different IKEd, documenting the changes, and fixing possible NO_INET/NO_INET6 related build issues. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On 27.12.2016 16:15, Jim Thompson wrote: In it's initial state if_ipsec allows to use only one set of encryption parameters (because only one sainfo anonyumous is possible), so at this time it doesn't allow to create multiple tunnels with VPN hubs that use different cipers and/or transform sets, but as far as I understand this is subject to change and Andrey is already working on a support of this feature from ipsec-tools IKE daemon. pfSense (which you mention below) is using strongswan, so when Andrey is finished with ipsec-tools, we will need to review his changes and see what we can do for strongswan. I'm looking forward to the mutliple-tunnel support, which is required for pfSense. There are no such limits. You can create multiple VTI interfaces. The problem is in with racoon configuration restrictions. It looks like ipsec-tools project is dead, I didn't received any replies from ipsec-tools-devel mailing list. I'm not aware how to configure strongswan, so if someone will not try to do this, I don't know when I will do this. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC/RFT] projects/ipsec
On 11.12.2016 02:07, Andrey V. Elsukov wrote: Hi All, I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in SADB/SPDB faster; * revise PFKEY implementation, remove stale code, make it closer to RFC; * implement IPsec VTI (virtual tunneling interface); * make IPsec code loadable as kernel module. Currently all, except the last one is mostly done. So, I decided ask for a help to test the what already done, while I will work on the last task. I finished the last task, now it is possible to load/unload IPsec and TCP-MD5 support as kernel modules. New kernel option IPSEC_SUPPORT should be used to build the kernel that is able to load IPsec module. So, if you have 'options IPSEC' in the kernel config, IPsec support will be build in the kernel without TCP-MD5 support. If you have 'options IPSEC' and 'options TCP_SIGNATURE', IPsec and TCP-MD5 support will be build in the kernel. If you have 'options IPSEC' and 'options IPSEC_SUPPORT', IPsec support will be build in the kernel and TCP-MD5 can be loaded. If you have 'options IPSEC_SUPPORT', IPsec and TCP-MD5 can be loaded. If you have 'options IPSEC_SUPPORT' and 'options TCP_SIGNATURE', TCP-MD5 support will be build in the kernel and IPsec can be loaded. If you have not IPSEC* options, it isn't possible to use IPsec as module. So, if there will no objection, I'll merge projects/ipsec into head/ within two weeks. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[RFC/RFT] projects/ipsec
Hi All, I am pleased to announce that projects/ipsec, that I started several months ago is ready for testing and review. The main goals were: * rework locking to make IPsec code more friendly for concurrent processing; * make lookup in SADB/SPDB faster; * revise PFKEY implementation, remove stale code, make it closer to RFC; * implement IPsec VTI (virtual tunneling interface); * make IPsec code loadable as kernel module. Currently all, except the last one is mostly done. So, I decided ask for a help to test the what already done, while I will work on the last task. How to try? There are no patches, you need to checkout the full projects/ipsec source tree, and build the kernel and the base system. There are very few changes in the base system, mostly the kernel changes. Thus for testing that old configuration is still work, it is enough to build only the kernel. The approximate list of changes that may be visible to users: * SA bundles now can have only 4 items in the chain. I think it is enough, I can't imagine configurations when needed more. Also now SA bundles supported for IPv6 too. * due to changes in SPDB/SADB, systems where large number of SPs and SAs are in use should get significant performance benefits. * the memory consumption should slightly increase. There are several hash tables and SP cache appeared. * INPCB SP cache should noticeable increase network performance of application when security policies are presence. https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html * use transport mode IPsec for forwarded IPv4 packets now unsupported. This matches the IPv6 behavior, and since we can handle the replies, I think it is useless. * Added net.inet.ipsec.check_policy_history sysctl variable. When it is set, each inbound packet that was handled by IPsec will be checked according to matching security policy. If not all IPsec transforms were applied, the check will fail, and packet will be dropped. * Many PF_KEY messages handlers was updated, probably some IKEd now may fail due to stricter checks. * SPI now unique for each SA. This also can break something. * Added if_ipsec interface. For more info look at https://svnweb.freebsd.org/base?view=revision=309115 https://reviews.freebsd.org/P112 * TCP_SIGNATURE code was reworked and now it behaves closer to RFC https://svnweb.freebsd.org/base?view=revision=309610 * NAT-T support was reworked. https://svnweb.freebsd.org/base?view=revision=309808 Also I made the patch to racoon that adds better support of NAT-T, you can use this port to build patched racoon: https://people.freebsd.org/~ae/ipsec-tools.tgz What results is interesting to me? If you have some nontrivial configuration, please test. If you have some configuration, that did't work, please test this branch. If you have performance problems, please test. But don't forget that this is head/ branch, you need to disable all debugging first. If you just want to test, pay attention to the output of `vmstat -m | egrep "sec|sah|pol|crypt"`. If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this support was significantly changed. PS. I just updated the branch to last head/, and it was not tested, sorry :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: netpfil with if_output and ip(6)_output
On 14.11.2016 16:13, Franco Fichtner wrote: > Hi Andrey, > >> On 14 Nov 2016, at 1:55 PM, Andrey V. Elsukov <bu7c...@yandex.ru> wrote: >> >> I have some thought related to your proposal. >> What you think if we will introduce new KPI to work with fwd_tags? >> With such KPI we can make fwd_tags opaque for PFIL consumers and handle >> tags identically in all *proto*_output() routines. >> >> For first glance I can propose the following: >> >> /* ip_var.h */ >> #define IP_HAS_NEXTHOP(m) ((m)->m_flags & M_IP_NEXTHOP) >> int ip_set_fwdtag(struct mbuf *m, struct sockaddr_in *dst, >>u_short ifidx); >> int ip_get_fwdtag(struct mbuf *m, struct sockaddr_in *dst, >>u_short *ifidx); >> void ip_flush_fwdtag(struct mbuf *m); >> >> >> /* ip6_var.h */ >> #define IP6_HAS_NEXTHOP(m) ((m)->m_flags & M_IP6_NEXTHOP) >> int ip6_set_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst, >>u_short ifidx); >> int ip6_get_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst, >>u_short *ifidx); >> void ip6_flush_fwdtag(struct mbuf *m); > > This looks reasonable, thank you. How would we proceed with the > implementation / porting of ipfw to the new framework? > >> Since I'm not quite aware how PF handles PACKET_TAG_IPFORWARD tags, you >> can modify this to fully cover its needs. > > Right now, it doesn't, which is the original problem: PACKET_TAG_IPFORWARD > aligns well with netpfil, now we only need pf to do the same (and > maybe the new ipfw net64 code at some point as well). nat64 does direct if_output only when undocumented IPFIREWALL_NAT64_DIRECT_OUTPUT option was used. In other cases (by default) translated packet will be scheduled via netisr. Also, do not forget that we have special handling for fwd_tags in udp/tcp output path. > ipfw only requires the forwarding address, pf will want to select > the outgoing interface in the same step so the KPI already covers > that. Yes, we get both ifindex and destination address from one call. In future ipfw(4) also can be extended to use ifindex. > As a note, set_fwdtag will have to be able to (safely) rewrite the > internal structure, in case one filter overwrites the decision of > the other, or we call flush + set again? In my meaning it should remove old tag and set new one. This can be optimized for cases when we have tag with nexthop for the same address family. > Another small oddity is the flipping of M_FASTFWD_OURS which is > write only for forwarding, but overwriting with another all requires > to unset it. Should M_FASTFWD_OURS set/unset be part of the KBI as > well? It looks like M_FASTWFD_OURS also can be covered by this KPI. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: netpfil with if_output and ip(6)_output
On 14.11.2016 15:24, Franco Fichtner wrote: > I've opened a review to start removal of if_output from the > pf code with a conservative first batch, which would eventually > enable ipfw and pf redirect packets using the same PACKET_TAG_IPFORWARD > mechanism. It was met with multiple opinions, but no agenda out > of the current situation: > > https://reviews.freebsd.org/D8109 > > Since the discussion went stale, I would like to pose three > questions to a wider audience: > > Is there interest in keeping the netpfil framework consistent > for use with either ipfw or pf? > > Is there interest in keeping the netpfil framework consistent > for use with ipfw and pf running at the same time? > > Is there anyone willing to review and guide work towards > correcting these oddities? Hi, I have some thought related to your proposal. What you think if we will introduce new KPI to work with fwd_tags? With such KPI we can make fwd_tags opaque for PFIL consumers and handle tags identically in all *proto*_output() routines. For first glance I can propose the following: /* ip_var.h */ #define IP_HAS_NEXTHOP(m) ((m)->m_flags & M_IP_NEXTHOP) int ip_set_fwdtag(struct mbuf *m, struct sockaddr_in *dst, u_short ifidx); int ip_get_fwdtag(struct mbuf *m, struct sockaddr_in *dst, u_short *ifidx); void ip_flush_fwdtag(struct mbuf *m); /* ip6_var.h */ #define IP6_HAS_NEXTHOP(m) ((m)->m_flags & M_IP6_NEXTHOP) int ip6_set_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst, u_short ifidx); int ip6_get_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst, u_short *ifidx); void ip6_flush_fwdtag(struct mbuf *m); Since I'm not quite aware how PF handles PACKET_TAG_IPFORWARD tags, you can modify this to fully cover its needs. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: was: CURRENT [r308087] still crashing: Backtrace provided
On 13.11.2016 12:23, O. Hartmann wrote: >>>>> Great, thank you. I would first like to confirm that r307234 is indeed >>>>> causing the crash - since it appears to be easy to trigger, that should >>>>> be faster. If not, the core will help track down the real problem. >>>> >>>> Although I was under the impression the in-kernel-config option >>>> >>>> makeoptionsDEBUG=-g >>>> >>>> would make debugging symbols available, I'm proved wrong. >> >> Do you have option FLOWTABLE in your kernel config? > > Would you suggest to disable this feature in the kernel? Or does the feature, > by > accident, influence the debugging ?? Hi, I never used FLOWTABLE, but as I know, when L2 caching was reintroduced the kernel with enabled FLOWTABLE has started crashing almost immediately. glebius@ added workaround in r300854 to prevent the panic. Then we discussed with him that the change in in_pcb.c should be reasonable. And he decided to revert the workaround. Now it seems without r300854 FLOWTABLE isn't usable. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: was: CURRENT [r308087] still crashing: Backtrace provided
On 08.11.2016 21:28, Mark Johnston wrote: > On Sun, Nov 06, 2016 at 11:13:56AM +0100, O. Hartmann wrote: >>> Great, thank you. I would first like to confirm that r307234 is indeed >>> causing the crash - since it appears to be easy to trigger, that should >>> be faster. If not, the core will help track down the real problem. >> >> Although I was under the impression the in-kernel-config option >> >> makeoptionsDEBUG=-g >> >> would make debugging symbols available, I'm proved wrong. Do you have option FLOWTABLE in your kernel config? >> #9 0x807b44fb in __rw_wlock_hard (c=, >> tid=, file=, >> line=) at /usr/src/sys/kern/kern_rwlock.c:830 Just my opinion. Setting RT_LLE_CACHE flag in ip_output is wrong. This flag should be set when ro_lle actually filled with cached data. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Trying to read linux-lvm on 11.0-RC2 using geom, bhyve, fail.
On 15.09.2016 08:10, Zaphod Beeblebrox wrote: > After this fail, I decided I didn't really _need_ to run linux here and I > discovered 'geom_linux_lvm.ko' ... cool. But fail, too. Doesn't emit any > messages. I even enabled the debug messages for it. > > The linux disk is partitioned thusly: > > =>63 1953525105 ada1 MBR (932G) > 631985- free - (993K) > 2048 1953523120 1 linux-data [active] (932G) Probably it isn't LVM or some modern version, which isn't supported by module. With enable kern.geom.linux_lvm.debug=1 module will complain only if it will find magic string "LABELONE" in the metadata. You can check what is stored in the metadata with the following command: # dd if=/dev/ada1s1 count=1 | hexdump -vC -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Destroy GPT partition scheme absolutely, how?
On 28.09.2016 22:02, Allan Jude wrote: > I wonder if this issue is related at all to the new 'auto resize' gpart > bits. That leaves the 'uncommitted' transaction pending, and may require > a 'gpart undo' before the other commands will work correctly. All other commands that do any changes will issue 'commit', so they will work correctly. I think you are confusing 'auto resize' with 'recovery needed'. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Destroy GPT partition scheme absolutely, how?
On 26.09.2016 23:51, John Baldwin wrote: >> Why not just use "gpart destroy -F provider"? > > That doesn't always work. In particular, if a disk was partitioned with GPT > and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the > MBR will leave most of the GPT intact and the disk will come up with the old > GPT partitions, not as a raw disk. If you would did `gpart destroy -F` for GPT, then it would not have appeared again. This is very strange problem, how did you created MBR if you have not destroyed GPT? :) After this commit it seems very unlikely to reproduce https://svnweb.freebsd.org/base?view=revision=292057 Described problem can be reproduced with BSD label. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CURRENT: [USB] : GEOM_PART: da4 was automatically resized.
On 01.08.16 12:05, O. Hartmann wrote: > On every(!) USB drive which worked well with 11-CURRENT up to 11-BETA, I fail > to access with 12-CURRENT (12.0-CURRENT FreeBSD 12.0-CURRENT #14 r303475: Fri > Jul 29 11:59:11 CEST 2016) with the error shown below. > > On USB flash drives I created myself, the suggested gpart command solved the > problem, but I can not do this with drives I was given by a vendor or > supplier. JFYI, r303637 fixes this problem for me. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ALPHA3 panic with ipfw+dummynet and gif/gre tunnels
On 17.06.16 04:03, Mark Felder wrote: > #8 0x80eb7a64 in trap (frame=0xfe0122831770) at > /usr/src/sys/amd64/amd64/trap.c:442 > #9 0x80e97f91 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #10 0x80c57ebc in ip6_output (m0=, > opt=, ro=, flags= optimized out>, im6o=0x0, ifpp=0x0, inp=) > at /usr/src/sys/netinet6/ip6_output.c:1060 > #11 0x82661fd2 in dummynet_send (m=) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800 > #12 0x82661890 in dummynet_task (context=, > pending=) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:746 > #13 0x80a9a1ac in taskqueue_run_locked (queue= out>) at /usr/src/sys/kern/subr_taskqueue.c:465 > #14 0x80a9acf8 in taskqueue_thread_loop (arg= out>) at /usr/src/sys/kern/subr_taskqueue.c:719 > #15 0x80a0b3e4 in fork_exit (callout=0x80a9ac70 > , arg=0x8266c8a8, > frame=0xfe0122831c00) at /usr/src/sys/kern/kern_fork.c:1038 > #16 0x80e984ce in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:611 > #17 0x in ?? () Hi, this is known issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209466 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162558 It looks the same, but for IPv6. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CURRENT: ipfw: problems with timeouts and worse network performance
On 20.05.16 17:23, O. Hartmann wrote: > I haven't checked so far whether the problem occurs also with non-SSL > connections since > all connections I see the suffering are somehow encrypted. Can you try to update up to r300302? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CURRENT: ipfw: problems with timeouts and worse network performance
On 20.05.16 17:23, O. Hartmann wrote: > The problem is simpel to trigger: have firewall type "WORKSTATION" > configured, IPFW > active (I have IPFW statically in-kernel-compiled, no modules so far). Have > /usr/src as a > svn+https repository and try a svn update of the source tree. Hi, it looks like r300143 broke it. I'm looking now why. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)
On 02.03.16 17:29, O. Hartmann wrote: > My interpretation of the above errors are: FreeBSD is incapable to handle CIFS > over tcp/445. The above URL/site claims to have solved the problem, but it > seems not true for CURRENT. Did you try some FUSE CIFS implementations? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panic: refcount inconsistency: found: 0 total: 1
On 04.11.2015 00:10, David Wolfskill wrote: > So... with the change from r290334, what's the point of the KASSERT? Yes, you are right. We changed this code and use it some time, but without INVARIANTS. I just removed this KASSERT in r290345. Can you try this revision? Sorry for the breakage. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: dumpdev in loader.conf vs rc.d/dumpon
On 24.09.2015 14:37, Slawa Olhovchenkov wrote: > For example, host with 3TB of RAM, booted from small SSD. > This SSD have 16GB slice for dumping. This is sufficent if trouble > happen at boot time. This is insuuficient if trouble happen later, > after using all 3TB. rc.d script can be used for select iSCSI > destination, for dumping after succesefull boot. Did you read dumpon script and saw how it uses dumpdev tunable? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: dumpdev in loader.conf vs rc.d/dumpon
On 24.09.2015 14:18, Slawa Olhovchenkov wrote: > On Thu, Sep 24, 2015 at 11:28:05AM +0300, Andrey V. Elsukov wrote: > >> On 23.09.2015 19:57, Andriy Gapon wrote: >>> I do not have a strong opinion. Either option, rc.d/dumpon change or >>> geom_dev >>> change, is fine with me. >> >> I added the ability to set dumpdev via loader. But I wasn't aware that >> it was used in rc.d script. >> >> If you have set dumpdev kenv, it will be already enabled in the time >> when rc.d/dumpon will be run. So, I think it is useless to try to >> enable dumpdev again. I prefer remove this old code from rc.d script. > > rc.d script can redirect dump to device, not available at boot time, > iSCSI disk, for examle. It doesn't matter. When device will appear, it will be tasted by geom_dev and marked as device applicable for dumping. > dumpdev at boot time can be less size, sufficient for dumping at > booting, but insufficient at working time. This also doesn't matter. Its size doesn't checked. Did you read dumpon script and saw how it use dumpdev tunable? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: dumpdev in loader.conf vs rc.d/dumpon
On 24.09.2015 14:45, Slawa Olhovchenkov wrote:
> On Thu, Sep 24, 2015 at 02:37:39PM +0300, Andrey V. Elsukov wrote:
>
>> On 24.09.2015 14:37, Slawa Olhovchenkov wrote:
>>> For example, host with 3TB of RAM, booted from small SSD.
>>> This SSD have 16GB slice for dumping. This is sufficent if trouble
>>> happen at boot time. This is insuuficient if trouble happen later,
>>> after using all 3TB. rc.d script can be used for select iSCSI
>>> destination, for dumping after succesefull boot.
>>
>> Did you read dumpon script and saw how it uses dumpdev tunable?
>
> This is script try it in case dumpdev=auto, before trying swap
> partition.
Yes.
1. If you did set dumpdev from loader prompt or from /boot/loader.conf,
and you didn't configured it in rc.conf, then this choice will be
applied by geom_dev. Then it will be applied again by rc.d/dumpon.
2. If you did set dumpdev from loader prompt or from /boot/loader.conf,
and you did configured it in rc.conf, then first of will be selected
dumpdev from loader, then will be selected one from rc.conf.
3. If you didn't set dumpdev from loader prompt or from
/boot/loader.conf, and you didn't configured it in rc.conf, then one of
swap partition will be selected.
In the end we can see, if we apply the following patch, then nothing
will be affected.
Index: dumpon
===
--- dumpon (revision 288047)
+++ dumpon (working copy)
@@ -34,11 +34,6 @@ dumpon_start()
[Nn][Oo] | '')
;;
[Aa][Uu][Tt][Oo])
- dev=$(/bin/kenv -q dumpdev)
- if [ -n "${dev}" ] ; then
- dumpon_try "${dev}"
- return $?
- fi
while read dev mp type more ; do
[ "${type}" = "swap" ] || continue
[ -c "${dev}" ] || continue
PS. loader(8) has many variables where device name is used, and none of
them uses /dev/ prefix.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: dumpdev in loader.conf vs rc.d/dumpon
On 23.09.2015 19:57, Andriy Gapon wrote: > I do not have a strong opinion. Either option, rc.d/dumpon change or geom_dev > change, is fine with me. I added the ability to set dumpdev via loader. But I wasn't aware that it was used in rc.d script. If you have set dumpdev kenv, it will be already enabled in the time when rc.d/dumpon will be run. So, I think it is useless to try to enable dumpdev again. I prefer remove this old code from rc.d script. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPSEC stop works after r285336
On 23.07.2015 10:38, Alexandr Krivulya wrote: I have IPSEC tunnel inside l2tp tunnel via mpd. After r285536 I see only outgoing esp packets on ng interface: What FreeBSD version do you use? Please check https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192774 and your security policies configuration. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: IPSEC stop works after r285336
On 24.07.2015 15:10, Alexandr Krivulya wrote: In that bug L2TP use IPSEC in transport mode, but in my scenario IPSEC in tunnel mode inside L2TP. And it works fine prior to r285536. But r285536 didn't touch head's source. This is commit into stable/10. So, it can't break something in 11.0-CURRENT. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Lenovo BIOS boot fix
On 12.07.2015 09:02, Allan Jude wrote:
I forgot to include the link to the patch as well:
http://www.allanjude.com/bsd/lenovofix_gpart.patch
I will most likely make this patch optional, behind a flag to the 'gpart
create -s gpt' command, to avoid potentially breaking existing working
systems, but if using offset 1 works on all other hardware, having it as
the default would be nice.
Another option would be to make a separate standalone program to modify
the pMBR for Lenovo machines, rather than modifying gpart.
Hi,
I think Lenovo's BIOS just think that your partition layout is MBR and
uses legacy boot.
if (MBR_partition[0].type == 0xee gpt_is_ok()) {
UEFI_boot();
} else {
MBR_boot();
}
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: Mbuf leak in if_lagg.c
On 19.03.2015 19:31, Alexandre Martins wrote:
Hi !
I found a leak of mbuf in the lagg driver :
https://svnweb.freebsd.org/base/head/sys/net/if_lagg.c?view=annotate#l1672
-=-=-=-=-=-=-=-=-=-=-
m = (lp-lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL;
-=-=-=-=-=-=-=-=-=-=-
If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it.
Can you look at this ?
Hi,
what you thing about this patch?
lp_detaching can be non zero in case of parent interface departure.
So I don't see the reason to call ETHER_BPF_MTAP() in this case.
--
WBR, Andrey V. Elsukov
Index: if_lagg.c
===
--- if_lagg.c (revision 280234)
+++ if_lagg.c (working copy)
@@ -1661,7 +1661,8 @@ lagg_input(struct ifnet *ifp, struct mbuf *m)
LAGG_RLOCK(sc, tracker);
if ((scifp-if_drv_flags IFF_DRV_RUNNING) == 0 ||
(lp-lp_flags LAGG_PORT_DISABLED) ||
- sc-sc_proto == LAGG_PROTO_NONE) {
+ sc-sc_proto == LAGG_PROTO_NONE ||
+ lp-lp_detaching != 0) {
LAGG_RUNLOCK(sc, tracker);
m_freem(m);
return (NULL);
@@ -1668,9 +1669,7 @@ lagg_input(struct ifnet *ifp, struct mbuf *m)
}
ETHER_BPF_MTAP(scifp, m);
-
- m = (lp-lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL;
-
+ m = lagg_proto_input(sc, lp, m);
if (m != NULL) {
if (scifp-if_flags IFF_MONITOR) {
m_freem(m);
signature.asc
Description: OpenPGP digital signature
Re: Mbuf leak in if_lagg.c
On 26.03.2015 22:42, Andrey V. Elsukov wrote:
If lp_detaching is non 0, the mbuf pointer is set to NULL without m_freem it.
Can you look at this ?
Hi,
what you thing about this patch?
lp_detaching can be non zero in case of parent interface departure.
So I don't see the reason to call ETHER_BPF_MTAP() in this case.
Now I see the reason - to capture all received packets before interface
departure. New is attached.
--
WBR, Andrey V. Elsukov
Index: if_lagg.c
===
--- if_lagg.c (revision 280234)
+++ if_lagg.c (working copy)
@@ -1669,7 +1669,11 @@ lagg_input(struct ifnet *ifp, struct mbuf *m)
ETHER_BPF_MTAP(scifp, m);
- m = (lp-lp_detaching == 0) ? lagg_proto_input(sc, lp, m) : NULL;
+ if (lp-lp_detaching != 0) {
+ m_freem(m);
+ m = NULL;
+ } else
+ m = lagg_proto_input(sc, lp, m);
if (m != NULL) {
if (scifp-if_flags IFF_MONITOR) {
signature.asc
Description: OpenPGP digital signature
Re: Possible race in IPv6
On 18.03.2015 20:01, Alexandre Martins wrote:
Dear,
I'm facing some crash around manipulations of IPv6 address.
I already found that the commit 275593 will fix my issue.
However, after some code review, i see a possible race in the function
nd6_na_input:
https://svnweb.freebsd.org/base/head/sys/netinet6/nd6_nbr.c?annotate=279676#l750
=-=-=-=-=-=-=-=-=-=
if (ifa
(((struct in6_ifaddr *)ifa)-ia6_flags IN6_IFF_TENTATIVE)) {
ifa_free(ifa);
nd6_dad_na_input(ifa);
goto freeit;
}
=-=-=-=-=-=-=-=-=-=
As you can see, the function drop its reference on the address and pass it to
nd6_dad_na_input.
It should be better to release the reference after the call.
What about you?
Hi,
Actually nd6_dad_na_input() uses ifa only for addresses comparison, so
there shouldn't be some negative impact in this race. But for the better
code logic I'll commit this change. Thanks.
--
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: Kernel Panic in frag6_slowtimeo
On 21.11.2014 09:10, Shawn Webb wrote: Looks like I’m getting a kernel panic on heavy work loads (poudriere run with 10 build slaves on an Intel Core i7 box). Below is a link to an imgur album of screenshots I took with my phone. Do you have VIMAGE option in your kernel? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
On 16.11.2014 09:15, John-Mark Gurney wrote: Ok, I was able to reproduce the bug, and found that my optimization for single mbuf packets was broken... I've attached a new patch that has the fix... This patch also has added a lock around the aesni fpu context setting to deal w/ the issue that I had... Let me know how things are w/ this new patch. Hi, with this patch all works as expected. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
On 15.11.2014 05:42, John-Mark Gurney wrote: John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 -0800: Well.. It looks like IPSEC is still broken in head... I can get pings to pass, but now on IPv4 transport mode, I can't get syn's to be sent out... I see the output packet in the protocol stats, but no packets go out the interface... If you could provide me w/ a simple set of spdadd commands, or the dumps from the machine, that'd be good... Hmm I just ran ping -f so I could generate some traffic, and managed to get a: panic: System call sendto returing with kernel FPU ctx leaked I'll look into this... I just verified that this happens on a clean HEAD @ r274534: FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 No modifications, nothing, and I got the same panic: panic: System call sendto returing with kernel FPU ctx leaked cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe001de7a800 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe001de7a8b0 vpanic() at vpanic+0x189/frame 0xfe001de7a930 kassert_panic() at kassert_panic+0x139/frame 0xfe001de7a9a0 amd64_syscall() at amd64_syscall+0x616/frame 0xfe001de7aab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001de7aab0 --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffee588, rbp = 0x7ffee5c0 --- KDB: enter: panic So, it's clearly not my patch that is causing the issue... Andrey, can you verify that you do not receive the same panic w/o my patches? 11.0-CURRENT r274469 after 20 minutes and # netstat -sp esp | grep out 424360710 packets out 17823149820 bytes out can't reproduce the panic. I'll update and retry on fresh CURRENT. My ipsec.conf: add 10.9.12.25 10.9.12.15 esp 15701 -E rijndael-cbc ; spdadd 192.168.0.0/16 192.168.0.0/16 any -P out ipsec esp/tunnel/10.9.12.25-10.9.12.15/default; aesni.ko is loaded and pmcstat shows that it is in use: PMC: [INSTR_RETIRED_ANY] Samples: 128994 (100.0%) , 7506 unresolved Key: q = exiting... %SAMP IMAGE FUNCTION CALLERS 13.5 kernel cpu_search_highest cpu_search_highest:11.3 sched_idletd:2.2 4.6 kernel __mtx_unlock_flags ip_output:0.8 key_checkrequest:0.6 ip_rtaddr:0.6 key_allocsp:0.5 4.0 kernel __mtx_lock_flags _key_freesp:0.8 rtalloc1_fib:0.8 key_checkrequest:0.6 3.5 kernel cpu_search_lowestcpu_search_lowest:2.6 sched_pickcpu:0.9 3.2 kernel bcopym_copydata:1.7 m_copyback:0.7 3.2 libc.so.7 bsearch 3.0 kernel __rw_rlock rtalloc1_fib 2.5 kernel uma_zalloc_arg malloc:0.8 crypto_getreq:0.6 2.4 kernel uma_zfree_argm_freem:1.0 free:0.7 2.2 kernel bzerouma_zalloc_arg 2.1 kernel _rw_runlock_cookie rtalloc1_fib:0.7 arpresolve:0.5 2.0 kernel rn_match rtalloc1_fib 1.7 kernel __mtx_lock_sleep __mtx_lock_flags 1.7 kernel ip_outputipsec_process_done:1.1 ip_forward:0.6 1.4 kernel critical_exitspinlock_exit 1.3 kernel spinlock_exitether_nh_input 1.3 kernel ixgbe_rxeof ixgbe_msix_que 1.2 kernel malloc 1.2 kernel critical_enter 1.2 kernel ixgbe_xmit ixgbe_mq_start_locked 1.1 aesni.ko aesni_encrypt_cbcaesni_process 1.1 kernel esp_output ipsec4_process_packet 1.1 kernel key_allocsp ipsec_getpolicybyaddr 1.0 kernel __mtx_lock_spin_flag 1.0 kernel in_cksumdata in_cksum_skip 1.0 kernel free 1.0 kernel ip_input netisr_dispatch_src 1.0 kernel ether_nh_input netisr_dispatch_src 1.0 kernel bounce_bus_dmamap_lo bus_dmamap_load_mbuf_sg 0.9 kernel _mtx_lock_spin_cooki pmclog_reserve 0.8 kernel m_copydata 0.8 kernel ipsec4_process_packe ip_ipsec_output -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
On 15.11.2014 05:42, John-Mark Gurney wrote: I just verified that this happens on a clean HEAD @ r274534: FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 No modifications, nothing, and I got the same panic: panic: System call sendto returing with kernel FPU ctx leaked cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe001de7a800 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe001de7a8b0 vpanic() at vpanic+0x189/frame 0xfe001de7a930 kassert_panic() at kassert_panic+0x139/frame 0xfe001de7a9a0 amd64_syscall() at amd64_syscall+0x616/frame 0xfe001de7aab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001de7aab0 --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffee588, rbp = 0x7ffee5c0 --- KDB: enter: panic So, it's clearly not my patch that is causing the issue... Andrey, can you verify that you do not receive the same panic w/o my patches? I tried 11.0-CURRENT r274549 with and without patches. Without patches all works as expected. System encrypts and forwards traffic with and without aesni module. With patches software rijndaelEncrypt also works. But when I load aesni.ko and restart setkey -f /etc/ipsec.conf forwarding stops, errors counter starts grow. And I see messages about wrong source route attempts from random addresses. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
On 14.11.2014 03:52, Andrey V. Elsukov wrote: I tried your patch with my IPv4 forwarding test. When aesni module is loaded and aes-cbc is used I see growing of `invalid outbound packets` counter in `netstat -sp ipsec` output. And no packets are forwarded. Also while testing I got a panic in aesni_encrypt_cbc(). atal trap 9: general protection fault while in kernel mode cpuid = 4; apic id = 04 instruction pointer = 0x20:0x80d05c43 stack pointer = 0x28:0xfe3f7e70 frame pointer = 0x28:0xfe3f7eb0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq286: ix0:que 4) The full backtrace is here: http://paste.org.ru/?a3f8pw Screenshot from ddb: http://i.imgur.com/H5mbVi8.png?1 Also I noticed that on higher packet rate sometimes kernel reports about wrong source route attempts: kernel: attempted source route from 244.116.138.102 to 225.51.107.139 kernel: attempted source route from 19.120.181.94 to 238.17.74.139 kernel: attempted source route from 186.217.142.184 to 233.165.4.102 kernel: attempted source route from 134.41.78.248 to 231.122.242.144 probably there is mbuf's memory corruption somewhere. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
0x80b170e9 in crypto_dispatch (crp=0xf80109f7bc08) at /usr/src/sys/opencrypto/crypto.c:807 #15 0x80b076d6 in esp_output (m=value optimized out, isr=value optimized out, mp=0x3, skip=value optimized out, protoff=value optimized out) at /usr/src/sys/netipsec/xform_esp.c:905 #16 0x80af7457 in ipsec4_process_packet (m=0xf8013b0de600, isr=value optimized out, flags=value optimized out, tunalready=value optimized out) at /usr/src/sys/netipsec/ipsec_output.c:594 #17 0x80a4a0db in ip_ipsec_output (m=value optimized out, inp=value optimized out, flags=0xfe3f8494, error=0xfe3f8490) at /usr/src/sys/netinet/ip_ipsec.c:332 #18 0x80a4b6b9 in ip_output (m=0xf8013b0de600, opt=value optimized out, flags=1, imo=value optimized out, inp=0x0) at /usr/src/sys/netinet/ip_output.c:476 #19 0x80a485eb in ip_forward (m=0xf8013b0de600, srcrt=value optimized out) at /usr/src/sys/netinet/ip_input.c:1571 #20 0x80a4825e in ip_input (m=0xf8013b0de600) at /usr/src/sys/netinet/ip_input.c:754 #21 0x809e7be1 in netisr_dispatch_src (proto=value optimized out, source=value optimized out, m=0xf8013b0de65a) at /usr/src/sys/net/netisr.c:968 #22 0x809dfb53 in ether_demux (ifp=value optimized out, m=0xf8013b0de600) at /usr/src/sys/net/if_ethersubr.c:766 #23 0x809e0758 in ether_nh_input (m=value optimized out) at /usr/src/sys/net/if_ethersubr.c:573 #24 0x809e7be1 in netisr_dispatch_src (proto=value optimized out, source=value optimized out, m=0xf8013b0de65a) at /usr/src/sys/net/netisr.c:968 #25 0x809dfdb6 in ether_input (ifp=value optimized out, m=0x0) at /usr/src/sys/net/if_ethersubr.c:674 #26 0x809e55e5 in vlan_input (ifp=0xf8000ef3e800, m=value optimized out) at /usr/src/sys/net/if_vlan.c:1239 #27 0x809dfac4 in ether_demux (ifp=0xf8000ef3e800, m=0xf8013b0de600) at /usr/src/sys/net/if_ethersubr.c:717 #28 0x809e0758 in ether_nh_input (m=value optimized out) at /usr/src/sys/net/if_ethersubr.c:573 #29 0x809e7be1 in netisr_dispatch_src (proto=value optimized out, source=value optimized out, m=0xf8013b0de65a) at /usr/src/sys/net/netisr.c:968 #30 0x809dfdb6 in ether_input (ifp=value optimized out, m=0x0) at /usr/src/sys/net/if_ethersubr.c:674 #31 0x8059f303 in ixgbe_rxeof (que=0xf8000ef5c1a0) at /usr/src/sys/dev/ixgbe/ixgbe.c:4530 Ermal (eri) has patches that enable AES-GCM (and I believe AES-CTR) support for our IPsec. Once these patches have been committed, I'll work with him to integrate his patch. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
[RFC][RFT] overhaul if_gre(4)
Hi All, I prepared the patch for review https://reviews.freebsd.org/D1023 Split if_gre(4) into two modules, if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * make implementation conform to the RFC 2784 and partially to RFC 2890; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove caching routes support. This fixes problem, when gre(4) doesn't work at system startup. But this also removes ability to have tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, use our standard ioctls for tunnels. me(4): * use the same locking model as gre(4); * use if_transmit; * implementation conform to RFC 2004; -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [RFC][RFT] overhaul if_gre(4)
On 29.10.2014 12:35, Andrey V. Elsukov wrote: Hi All, I prepared the patch for review https://reviews.freebsd.org/D1023 For those who want to test, I prepared a tarball with sources https://people.freebsd.org/~ae/gre.tgz Modules should work on stable/10 and head/ without modifications. And they will not work on stable/9. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: ipv6 network aliases not set after upgrade to 9.3
On 04.09.2014 18:16, Kurt Lidl wrote: Greetings all: I have a host that recently was upgraded from FreeBSD 9.1 to FreeBSD 9.3. After the upgrade, the IPv6 aliases that I was setting on vlan'd interfaces, no longer get set: The section of my /etc/rc.conf, which worked under 9.1: # inside network (gigabit connected) ifconfig_bce1=up vlans_bce1=16 17 ifconfig_bce1_16=192.168.16.4/24 ifconfig_bce1_16_ipv6=inet6 accept_rtadv ifconfig_bce1_16_alias0=inet6 2001:470:e254:0010::4 prefixlen 64 alias ifconfig_bce1_17=192.168.17.4/24 ifconfig_bce1_17_ipv6=inet6 accept_rtadv ifconfig_bce1_17_alias0=inet6 2001:470:e254:0011::4 prefixlen 64 alias When I use the same configuration file under 9.3, I get the vlan'd interfaces created, and they get an auto-assigned IPv6 interface, but the aliases do not get assigned. If I manually run: ifconfig bce1.16 inet6 2001:470:e254:0010::4 prefixlen 64 alias ifconfig bce1.17 inet6 2001:470:e254:0011::4 prefixlen 64 alias Then the aliased addresses get assigned. Did the syntax for specifying aliases on vlan'd interfaces change subtly for 9.3 vs 9.1? I did not see anything calling out this change in either the 9.2 or 9.3 release notes. Hi, I can confirm this, please, fill a bug report. -- 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: mkimg used to create gpt image, problem booting
On 24.08.2014 19:23, Marcel Moolenaar wrote:
On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov bu7c...@yandex.ru wrote:
On 24.08.2014 06:14, Craig Rodrigues wrote:
I did some further debugging inside the loader by doing the following.
- I added CFLAGS += -DPART_DEBUG to sys/boot/common/Makefile.inc
- I added DEBUG() statements all over sys/boot/common/part.c
I observed that in sys/boot/common/part.c in the ptbl_gptread() function,
that in this section:
305 ent = (struct gpt_ent *)tbl;
306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz,
307 MAXTBLSZ * table-sectorsize);
308 for (i = 0; i size / hdr.hdr_entsz; i++, ent++) {
309 if (uuid_equal(ent-ent_type, gpt_uuid_unused,
NULL))
310 continue;
ent-ent_type is all 0's, which matches gpt_uuid_unused, so it bails
out of the loop and never adds the gpt partitions to the list of partitions
that the loader can access.
Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
Actually, no. There is *a* problem in that function:
The function does not respect hdr.hdr_entsz when it
needs the next entry. It simply uses ent++, which
is fixed our definition of struct gpt_ent and may
not match the definition of the writer.
Yes, you are right. I'll fix this. Thanks.
I don't see how the loader is responsible for *the*
problem. All I see in qemu is that the loader, when
it reads a sector, isn't getting the actual sector
data that's in the image.
Just do a ktrace on qemu and you'll see what I mean.
YMMV of course,
Also there is bootparttest utility in the tools/tools/bootparttest. I
think it can be useful for debugging.
--
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: mkimg used to create gpt image, problem booting
On 24.08.2014 20:59, Craig Rodrigues wrote: Also, in the gptboot man page, it mentions that gptboot can only boot on systems with 128 partitions or less. This seems like an artificial restriction. Does the gptboot code really enforce this? Not that I have a system with more than 128 partitions. :) It's because gptboot uses static buffer to read and write GPT table. -- 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: mkimg used to create gpt image, problem booting
On 25.08.2014 03:55, Marcel Moolenaar wrote: Though, w/ people dd'ing images onto disks, and using growfs to grow as necessary, we might want to allocate a few more more than the minimum... I do agree that we want to keep sizes to a minimum... One thing I can maybe do is simply fill the empty sectors that are there because of alignment. If you add -P 4K to mkimg, then the first partition will by 4K aligned and you have about 5 sectors unused between the end of the GPT table and the first sector of the first partition. I may as well extend the table to cover those unued sectors. IMHO, mkimg should behave like gpart and create images in gpart-compatible way. Some users may want to copy the partition layout from the image to real hardware and they will not be able to do it. Also, now FreeBSD 11.0 uses different first usable LBA. By default it is 4k aligned. And this creates some incompatibility with older versions. You can't do `gpart restore` and get the same table, as you had on older system. However, this is a pretty side-ways way to end up with a GPT table that has some extra room. Maybe having scheme- specific options for this kind of thing is not bad. At least EBR and APM have the same problem and the BSD disk label can also be created with more than just 8 partitions. I thought about implementing `gpart modify` or `gpart set` -n entries to change number of entries when it is possible (i.e. disklabel(8) can do it, but gpart doesn't). Also in r228076 I changed APM code to calculate maximum number of entries depending from available free space. -- 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: mkimg used to create gpt image, problem booting
On 25.08.2014 18:40, Marcel Moolenaar wrote: Also, now FreeBSD 11.0 uses different first usable LBA. By default it is 4k aligned. And this creates some incompatibility with older versions. You can't do `gpart restore` and get the same table, as you had on older system. It sounds restore is broken then. The restore command cannot ever assume anything about the GPT. Including the tool that created the GPT. In order to restore a GPT, it must be properly backed-up. The backup header and table should suffice most of the time for that purpose as it's a replica, but as soon as meta-data is missing and the restore command has to guess, things will go wrong. `gpart restore` just uses a number of commands to geom_part(4) to create partition table similar to what was backed up. If your partition table on the old system had a partition that starts from LBA 34, now `gpart create` isn't able to create such partition table. Because by default the first usable LBA is 40. -- 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: mkimg used to create gpt image, problem booting
On 24.08.2014 06:14, Craig Rodrigues wrote:
Hi,
I did some more experiments, and found that after /boot/loader runs,
if I break into the loader prompt and type lsdev, I would get this:
(1) GPT Disk image which boots under QEMU, made by bsdinstall
==
View from loader
OK lsdev
cd devices:
disk devices:
disk0:BIOS drive A:
disk1:BIOS drive C:
disk1p1: FreeBSD boot
disk1p2: FreeBSD UFS
disk1p3: FreeBSD swap
pxe devices:
View from gpart, after we mdconfig the disk image
= 34 10485693 md0 GPT (5.0G)
34 1281 freebsd-boot (64K)
162 99592962 freebsd-ufs (4.7G)
99594585242883 freebsd-swap (256M)
10483746 1981 - free - (991K)
(2) GPT Disk image which fails to boot under QEMU, made by mkimg
===
View from loader
OK lsdev
cd devices:
disk devices:
disk0:BIOS drive A:
disk1:BIOS drive C:
pxe devices:
View from gpart, after we mdconfig the disk image
= 3 1784944 md1 GPT (872M)
3 321 freebsd-boot (16K)
35 17849122 freebsd-ufs (872M)
This leads me to believe that there is logic in /boot/loader,
which is not in GEOM, that fails to parse the GPT produced by mkimg.
I did some further debugging inside the loader by doing the following.
- I added CFLAGS += -DPART_DEBUG to sys/boot/common/Makefile.inc
- I added DEBUG() statements all over sys/boot/common/part.c
I observed that in sys/boot/common/part.c in the ptbl_gptread() function,
that in this section:
305 ent = (struct gpt_ent *)tbl;
306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz,
307 MAXTBLSZ * table-sectorsize);
308 for (i = 0; i size / hdr.hdr_entsz; i++, ent++) {
309 if (uuid_equal(ent-ent_type, gpt_uuid_unused,
NULL))
310 continue;
ent-ent_type is all 0's, which matches gpt_uuid_unused, so it bails
out of the loop and never adds the gpt partitions to the list of partitions
that the loader can access.
I'm not familiar with the GPT format, nor am I familiar with the
gpt code inside the loader, and how it differs from GEOM.
Do you have any further ideas of where to hunt for the root cause of
the problem?
Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On 20.07.2014 18:15, Maxim Khitrov wrote: In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. Even if you just drop current PF from FreeBSD, there is nobody, who want to port new PF from OpenBSD. And this is not easy task, as you may think. Gleb has worked on rewriting PF more than half year. So, return back all improvements after import will be hard enough and, again, nobody want to do it. :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: diskid documentation
On 02.06.2014 01:32, Adam McDougall wrote: Also, I believe it is only in 10.0-RELEASE and higher. Even if your kernel supports it, /dev/diskid will not exist if no hardware is found with supported strings (tested in a VM just now). Probably, they just disappeared like all other labels, when you got access to disk not through the label. -- 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: gpart destroy, zpool destroy, zfs destroy under securelevel 3
On 26.05.2014 17:31, Vladimir Sharun wrote: Hello FreeBSD community, Recently plays with securelevel and what I discover: no chance for data to survive against remote root, except backups of course. Maybe this log can be a proposal for raising securelevel further or include securelevel support against the software which can deal with zfs and GEOM labels ? Hi, if you have root privileges you can just write some random bytes in some places and this will be enough to break your system. So, restricting some gpart's or zpool's actions depending from securelevel looks like protection from kids. -- 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: gpart destroy, zpool destroy, zfs destroy under securelevel 3
On 29.05.2014 12:56, Vladimir Sharun wrote: Hello, if you have root privileges you can just write some random bytes in some places and this will be enough to break your system. So, restricting some gpart's or zpool's actions depending from securelevel looks like protection from kids. Having root under securelevel 3 confirmed disallows you to: 1) Direct write to the block devices such as (a)da 2) Change rules and/or shutdown pf 3) Remove system flags such as schg, sunlnk I think your statement true in case of securelevel -1, we're talking about the highest one - 3, which shown in logs. Ok, you are right. But geom_dev restricts access only from user level applications. When GEOM object does access directly via GEOM methods this protection won't work. And it seems it isn't easy to fix, all classes should have own check. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
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 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: [rfc] removing the NDISulator
On 19.10.2013 10:01, Thomas Mueller wrote: I too would like to see more effort writing new Ethernet and wifi drivers and porting from other operating systems. But I would like to keep the NDISulator/NDISwrapper as a fallback. There are still wifi adapters, Ethernet too, where there is no FreeBSD driver (AR9271 for instance), or the FreeBSD driver is buggy. I'm agree. While there are still some devices without native drivers, but that work via NDISulator, we should keep it. -- 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: IPSEC crashes after r253088
On 21.07.2013 00:43, Taku YAMAMOTO wrote: After r253088, systems with IPSEC and KSTACK_PAGES 4 crashes on booting into multi-user mode. The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with kernel stack overflow. where type is struct ipsecstat which is 12560 bytes of size (larger than 3 pages) of size when processing net.inet.ipsec.ipsecstats. Hi, Only few fields of struct ipsecstat is used, the rest fields are never updated. We can split it to several structures, or just remove unused fields. What is better? -- 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: IPSEC crashes after r253088
On 23.07.2013 15:28, Andre Oppermann wrote: On 23.07.2013 09:28, Andrey V. Elsukov wrote: On 21.07.2013 00:43, Taku YAMAMOTO wrote: After r253088, systems with IPSEC and KSTACK_PAGES 4 crashes on booting into multi-user mode. The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with kernel stack overflow. where type is struct ipsecstat which is 12560 bytes of size (larger than 3 pages) of size when processing net.inet.ipsec.ipsecstats. Hi, Only few fields of struct ipsecstat is used, the rest fields are never updated. We can split it to several structures, or just remove unused fields. What is better? Not storing it on the stack? It seems that only about 120 bytes are used from all 12 Kbytes. The old ipsecstat structure was concatenated with newipsecstat some time ago. And in fact, only fields of newipsecstat are used. I see no sense to just waste 12*ncpu Kbytes of memory. -- 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: IPSEC crashes after r253088
On 23.07.2013 15:28, Andre Oppermann wrote:
On 23.07.2013 09:28, Andrey V. Elsukov wrote:
On 21.07.2013 00:43, Taku YAMAMOTO wrote:
After r253088, systems with IPSEC and KSTACK_PAGES 4 crashes on
booting into multi-user mode.
The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with
kernel stack overflow.
where type is struct ipsecstat which is 12560 bytes of size (larger than
3 pages) of size when processing net.inet.ipsec.ipsecstats.
Hi,
Only few fields of struct ipsecstat is used, the rest fields are never
updated. We can split it to several structures, or just remove unused
fields. What is better?
Not storing it on the stack?
Also, I already prepared patch to test.
--
WBR, Andrey V. Elsukov
Index: sys/netinet/sctp_input.c
===
--- sys/netinet/sctp_input.c(revision 253562)
+++ sys/netinet/sctp_input.c(working copy)
@@ -5705,7 +5705,7 @@ sctp_common_input_processing(struct mbuf **mm, int
#ifdef INET
case AF_INET:
if (ipsec4_in_reject(m, inp-ip_inp.inp)) {
- IPSECSTAT_INC(in_polvio);
+ IPSECSTAT_INC(ips_in_polvio);
SCTP_STAT_INCR(sctps_hdrops);
goto out;
}
@@ -5714,7 +5714,7 @@ sctp_common_input_processing(struct mbuf **mm, int
#ifdef INET6
case AF_INET6:
if (ipsec6_in_reject(m, inp-ip_inp.inp)) {
- IPSEC6STAT_INC(in_polvio);
+ IPSEC6STAT_INC(ips_in_polvio);
SCTP_STAT_INCR(sctps_hdrops);
goto out;
}
Index: sys/netinet/tcp_input.c
===
--- sys/netinet/tcp_input.c (revision 253562)
+++ sys/netinet/tcp_input.c (working copy)
@@ -899,12 +899,12 @@ findpcb:
#ifdef IPSEC
#ifdef INET6
if (isipv6 ipsec6_in_reject(m, inp)) {
- IPSEC6STAT_INC(in_polvio);
+ IPSEC6STAT_INC(ips_in_polvio);
goto dropunlock;
} else
#endif /* INET6 */
if (ipsec4_in_reject(m, inp) != 0) {
- IPSECSTAT_INC(in_polvio);
+ IPSECSTAT_INC(ips_in_polvio);
goto dropunlock;
}
#endif /* IPSEC */
Index: sys/netinet/udp_usrreq.c
===
--- sys/netinet/udp_usrreq.c(revision 253562)
+++ sys/netinet/udp_usrreq.c(working copy)
@@ -282,7 +282,7 @@ udp_append(struct inpcb *inp, struct ip *ip, struc
/* Check AH/ESP integrity. */
if (ipsec4_in_reject(n, inp)) {
m_freem(n);
- IPSECSTAT_INC(in_polvio);
+ IPSECSTAT_INC(ips_in_polvio);
return;
}
#ifdef IPSEC_NAT_T
@@ -1294,7 +1294,7 @@ udp4_espdecap(struct inpcb *inp, struct mbuf *m, i
if (minlen m-m_pkthdr.len)
minlen = m-m_pkthdr.len;
if ((m = m_pullup(m, minlen)) == NULL) {
- IPSECSTAT_INC(in_inval);
+ IPSECSTAT_INC(ips_in_inval);
return (NULL); /* Bypass caller processing. */
}
data = mtod(m, caddr_t);/* Points to ip header. */
@@ -1334,7 +1334,7 @@ udp4_espdecap(struct inpcb *inp, struct mbuf *m, i
uint32_t spi;
if (payload = sizeof(struct esp)) {
- IPSECSTAT_INC(in_inval);
+ IPSECSTAT_INC(ips_in_inval);
m_freem(m);
return (NULL); /* Discard. */
}
@@ -1355,7 +1355,7 @@ udp4_espdecap(struct inpcb *inp, struct mbuf *m, i
tag = m_tag_get(PACKET_TAG_IPSEC_NAT_T_PORTS,
2 * sizeof(uint16_t), M_NOWAIT);
if (tag == NULL) {
- IPSECSTAT_INC(in_nomem);
+ IPSECSTAT_INC(ips_in_nomem);
m_freem(m);
return (NULL); /* Discard. */
}
Index: sys/netinet6/ip6_forward.c
===
--- sys/netinet6/ip6_forward.c (revision 253562)
+++ sys/netinet6/ip6_forward.c (working copy)
@@ -120,7 +120,7 @@ ip6_forward(struct mbuf *m, int srcrt)
* before forwarding packet actually.
*/
if (ipsec6_in_reject(m, NULL)) {
- IPSEC6STAT_INC(in_polvio);
+ IPSEC6STAT_INC(ips_in_polvio);
m_freem(m);
return;
}
@@ -182,7 +182,7 @@ ip6_forward(struct mbuf *m, int srcrt)
sp = ipsec_getpolicybyaddr(m, IPSEC_DIR_OUTBOUND,
IP_FORWARDING, error);
if (sp == NULL) {
- IPSEC6STAT_INC(out_inval);
+ IPSEC6STAT_INC(ips_out_inval);
IP6STAT_INC(ip6s_cantforward
Re: Booting an alternative kernel from loader prompt fails the first time only
On 21.04.2013 04:36, Steven Hartland wrote: This fails and trips the Restart from the beginning case which contains: last_file_format = i = 0; fp = NULL; continue; So i gets set to 0 but the loop then increments it to 1 before running the next iteration, so its impossible to use first handler in the retry case; which I suspect is the kernel loader. This also explains why the second call to boot works as last_file_format is now 0 due to the previous failure. If this is the issue the attached patch should fix it. I can't test it ATM as my current box is at the office and doesn't have remote KVM, so I need to be in front of it. If anyone can confirm this attached patch fixes the problem then I'll get it committed, otherwise I'll test on Monday. Hi, yes, you are right. I just committed this with r249719. Thanks. -- 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: sysutils/fusefs-kmod problem in CURRENT
On 27.03.2013 07:00, Marcelo/Porks wrote: Sorry, maybe I didnt understand what you said. I tried to use in my kernel conf: options FUSEFS option FUSEFS options fusefs option fusefs But they didnt work. The kernel does not compile. The result is above: Hi, you can just load the kernel module fuse.ko. Fuse is in the base system. -- 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: gpart on macbook air
On 30.09.2012 23:06, Raoul MEGELAS wrote: When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. I can understand that, but i would have thought that the deletion of the concerned partition was written preserving others??? something like: - read the gpt table - find the offset - zeroes the partition entry - rewrites the table? is not that logic? if it is not so, i does not understand this behaviour. Hi, Raoul, The kernel has a copy of the partition table in the memory. When you are deleting some partition, it removes the partition entry from the memory, constructs updated GPT header and table, calculates checksums and writes this data into corresponding places. Any way, this should correctly work. My guess is that Apple's boot loader detects some changes and just doesn't want to work. If you think that gpart incorrectly works, please make a copy of first 34 blocks before and after deletion and send them to me. -- 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: gpart on macbook air
On 30.09.2012 20:37, Raoul MEGELAS wrote: i installed CURRENT on a macbook air (internal ssd as you know): i noticed the following: 1. on freebsd, deleting a partition with gpart: say gpart delete -i 4 ada0 dammage the osx boot. of cours, booting with a backup disk and repairing the disk make it functional again. any light woukd be appreciated on this topic. Hi, When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. -- 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: Trying current
On 29.09.2012 04:00, Brett wrote: Hi list, I'm getting and old core2duo today to install FreeBSD (hopefully current) on it. Looking in the ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ folder for the last week or so, there have been no snapshots in there. Do they still come out roughly monthly and/or is one likely to appear soon? Hi, There are snapshots created by Hiroki Sato, i use it regularly and they are ok. https://pub.allbsd.org/FreeBSD-snapshots/ -- 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: gptzfsboot problem on HP P410i Smart Array
On 19.08.2012 11:22, Bjorn Larsson wrote: We are having problems with gptzfsboot on a HP DL360 G7 using the P410i Smart Array Controller. I’ve some information on this in the archive on this mailing list that this has supposedly been fixed with revision 227400, by implementing the edd data structure. However we still see the same problem and by adding a printf() in zfsboot.c fixes the problem. Please, let me know if anyone have seen this problem and if there is a fix for it? Hi, what exactly do you have? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: zfsloader failure with r239244
On 14.08.2012 21:03, Steve Wills wrote: Any ideas if this is a bug or something wrong with my system would be appreciated. Can you boot with serial console and show what show the `lsdev` command in the loader? And from the running system the output of `gpart show` and `zpool status`. -- 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: geom mirror now rebuilding on every reboot?
On 07.08.2012 04:03, Tom Uffner wrote: GEOM_RAID: Promise: Array Promise Created GEOM_RAID: Promise: Disk ad4 state changed from NONE to SPARE GEOM_MIRROR: Cannot open consumer ad4 (error=1) GEOM_MIRROR: Cannot add disk ad4 to gm0 (error=1) wondering if anyone knew offhand what is going on how to fix it. You can remove options GEOM_RAID from your kernel config. -- 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
[Request for review] loader changes
Hi, All.
It's been a long ago, when i published my patches first time.
And it seems, there is no one who is against or wants suggest something.
So I'm asking for review, and I want start merge changes at the end of week.
Patches are here: http://people.freebsd.org/~ae/bootcode/
full.diff:
The full diff, except tools.
tools.diff:
A small test program bootparttest. It uses sys/boot/common/part.c to
taste GEOM provider or disk image in the similar way, how loader does.
common.diff:
Changes to the common code. This code is used with many architectures and
libraries.
* common/Makefile.inc
added LOADER_NO_DISK_SUPPORT knob to disable build common code related to
disks and
partitions. By default GPT and MBR support are enabled, LOADER_NO_GPT_SUPPORT
and
LOADER_NO_MBR_SUPPORT can disable they.
* common/part.c
common/part.h
these files are new. They contains partition tables related code. Several
words about API:
Partition table described with opaque type struct ptable, partition entries
with
struct ptable_entry {
uint64_tstart;
uint64_tend;
int index;
enum partition_type type;
};
The partition tables detection occurs when ptable_open() is called. This
function takes
as arguments the number of disk sectors, sector size and pointer to the
callback
function, that is know how to read from the disk.
The ptable_close() function releases allocated resources.
The ptable_gettype() functions returns the type of partition table.
The ptable_getpart() functions returns information about specified partition.
The ptable_iterate() functions calls a callback function for each partition
in the table.
The parttype2str() converts partition type to the string.
The following partition tables are supported: BSD label, GPT, MBR, EBR and
VTOC8.
* common/disk.c
common/disk.h
These files have been changed and they use new API to work with partitions.
Also now
they provide new disk API to the devsw disk drivers: disk_open(),
disk_close(),
disk_print(), disk_fmtdev() and disk_parsedev().
i386.diff:
Changes related to the i386 architecture:
* i386/libi386/devicename.c
Use disk_fmtdev() and disk_parsedev() functions from the common code.
* i386/libi386/biosdisk.c
The disk driver was rewritten to use new disk API. To the devsw ioctl handler
was added.
It handles DIOCGSECTORSIZE and DIOCGMEDIASIZE ioctls.
* i386/libi386/libi386.h
The offset field was added to the i386_devdesc.d_kind.biosdisk structure.
* i386/libi386/Makefile
removed unneeded flag.
* i386/pmbr/pmbr.s
Added secondary GPT support.
* i386/loader/main.c
ZFS probing simplified.
* i386/loader/Makefile
removed unneeded flag.
userboot.diff:
The disk driver and sample program updated according to the changes in the
disk.c.
Also new diskioctl callback added.
uboot.diff:
The disk driver was rewritten to use new disk API.
arm.diff:
powerpc.diff:
Added LOADER_NO_DISK_SUPPORT handling to be able build uboot with or without
disk support.
zfs.diff:
Use new partitions API to probe all ZFS partitions in the GPT and BSD partition
tables.
So, if there will not any opinions against these APIs and patches I will start
commit. The first step will be common and userboot code, then - i386 and zfs
parts.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 16.07.2012 14:23, Andriy Gapon wrote: on 26/06/2012 15:50 Andrey V. Elsukov said the following: 3. ZFS code now uses new API and probing on the systems with many disks should be greatly increased: zfs/zfs.c i386/loader/main.c First of all, it's hard to parse the above sentence. probing ... should be greatly increased. Probing what? :-) If probing time, then we don't want that ;-) I looked through the ZFS-related part and here are a few comments: Thanks for that. 1. I think that the predominant indentation style of i386/loader/main.c should be preserved for consistency. 2. I am not sure if I like the approach of moving partition tasting code into common ZFS code (zfs.c). On one hand, it now makes sense because the new partition iteration code is machine-independent. On the other hand, the reason that I added arch_zfs_probe method was to give platforms full control over which partitions and in what order are probed. It seems to be important for some of them. So, I like how your new partition interface makes it much easier to ZFS-probe partitions, but I would prefer to have that code in arch_zfs_probe implementations rather than in zfs_probe_dev. From the other point of view, ZFS is not a just file system and it works directly with disks and partitions. And it seems to me this code will be common for other architectures. 3. Related to the above. In what shape is sparc64 ZFS support in your branch? Have you tried to adapt it to the new model too? It's the platform that has special requirements for disk/partition probing order. Marius can help with additional information and testing here. Currently i have not received any feedback reports from the users who can test patches on the other architectures. I added VTOC8 support to the part.c, but it seems it is not needed and ofw can work without this. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 16.07.2012 15:05, Andriy Gapon wrote: 2. I am not sure if I like the approach of moving partition tasting code into common ZFS code (zfs.c). On one hand, it now makes sense because the new partition iteration code is machine-independent. On the other hand, the reason that I added arch_zfs_probe method was to give platforms full control over which partitions and in what order are probed. It seems to be important for some of them. So, I like how your new partition interface makes it much easier to ZFS-probe partitions, but I would prefer to have that code in arch_zfs_probe implementations rather than in zfs_probe_dev. From the other point of view, ZFS is not a just file system and it works directly with disks and partitions. And it seems to me this code will be common for other architectures. Well, it seems that you haven't yet touched sparc64_zfs_probe. Yes. It should work as before. But if Marius can suggest how to change ofw_disk.c to get disk size and sector size, then i will be able to break something here :) If you'll find that you don't have to use any ugly hacks there, then good. But my impression is that it would be easier to stick to the previous approach. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 16.07.2012 15:31, Andriy Gapon wrote: Yes. It should work as before. Well, but it's obvious that zfs_probe_dev would be attempting to do some unneeded stuff (trying to treat partitions as disks) for that case. To me this is a clear indication zfs_probe_dev is not optimal for arch-independent implementation. So I still think that arch_zfs_probe should decide what disks and partitions to probe, and zfs_probe_dev should only probe what it's given and not try to be any smarter. But I've repeated myself three times already :-) And we will have the same - several copies of the same code in each architecture, which i have deleted... Sparc doesn't support DIOCGMEDIASIZE and DIOCGSECTORSIZE ioctls, so it will not check each partition, only fd that is passed to the zfs_probe_dev. Currently there is only one problem with ZFS tasting, that can affect users - now we taste each disk and partition, but in the my branch ZFS tastes only disks and partitions with type freebsd and freebsd-zfs. So if you have created ZFS on top of MBR partition with type ntfs, then loader will be unable to detect it. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 29.06.2012 15:01, Jan Beich wrote: So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff FWIW, I verified it compiles OK with clang, and especially boot2's size isn't increased at all. Does it boot for you? Same if I build zfs.c with gcc -O0: FreeBSD/x86 ZFS enabled bootstrap loader, Revision 1.1 (foo@bar, Tue Jun 26 18:52:52 UTC 2012) ZFS: can't find pool by guid ZFS: can't find pool by guid can't load 'kernel' Does zfsloader without patches compiled with CLANG work for you? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 13:19, Boris Samorodov wrote: 27.06.2012 23:27, Andrey V. Elsukov пишет: 1. You are against from: Our loader detects that primary GPT header is damaged. It tries to read backup GPT header from the last LBA and it detects that there is GEOM:: signature. It tries to read one previous sector and there is *valid* GPT header. Can we do the other way round? I.e. the GPT header is at the last sector. And if GEOM singature is not found at last sector of the disk and this sector is a GPT header then look at the previous sector? Then this sector contains GPT table. -- 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: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 14:35, Wojciech Puchar wrote: Just modify GEOM classes that keep state at the end of a partition to leave some spare area *behind* the GEOM data. I.e.: what is really a problem aat all? just leave as is. If someone want's use gpart and mirror then mirroring every partition is simpler. usually not every partition needs to be mirrored. or mirror a whole and make gpart in it, it should still boot fine. I already reverted changes related to the GPT and GEOM metadata detection. even better - update bsdlabel to work with 2TB devices. MUCH better. DragonFlyBSD has disklabel64 partitioning scheme. Make a port is simple task. -- 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: [CFC/CFT] large changes in the loader(8) code
On 28.06.2012 15:36, Boris Samorodov wrote: 28.06.2012 14:10, Stefan Esser пишет: All of the above is ugly, U'm afraid :( One more try to overcome it. :-) We already have freebsd-boot partition at GPT scheme. Right? Then why not use it (dedicated file/part/etc.) to store geom FreeBSD information? Recently i have ported LDM support to the FreeBSD. LDM uses 1Mbytes to store its database. All disks that are used by LDM have this database. When the disk is partitioned with MBR, LDM is stored in the last 1Mbyte. When the disk is partitioned with GPT, one partition is dedicated to this database. LDM is not just partitioning scheme, it is also LVM and can do RAID0-5. This is how Microsoft and Veritas have resolved this problem. -- 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: [CFC/CFT] large changes in the loader(8) code
On 27.06.2012 16:07, John Baldwin wrote: • Check the Signature • Check the Header CRC • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table • Check the CRC of the GUID Partition Entry Array If the GPT is the primary table, stored at LBA 1: • Check the AlternateLBA to see if it is a valid GPT If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. Right, we break the last rule. If you want to use a partition editor that doesn't grok gmirror (because you are using another OS's editor), to repair a GPT, it will do the wrong thing. When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class. It only sends control requests to the kernel. If GPT is not detected, there is no geom objects to manage. And we can't write bootcode with gpart(8). I think that adding such functions to the gpart(8) is not good. Maybe, the boot0cfg is the better tool for that. Also we still haven't any tool to install zfsboot. We can't write bootcode with gpart? What do you think the 'bootcode' command does? `gpart bootcode -b` reads file, creates ioctl request and sends this data to the GEOM_PART class. GEOM_PART receives the control request, checks the data and writes it to the provider. `gpart bootcode -p` works like dd(1) and writes bootcode to the given partition. gpart(8) haven't any knowledge about specific partitioning scheme. Also, there is no reason we can't have a 'recover' command that attempts to recover a corrupted table including repairing the PMBR. gpart(8) already generates a full PMBR when you use 'gpart create' to create a GPT even though there isn't a GPT object yet. `gpart create` creates only ioctl control request to the GEOM_PART class. GEOM_PART class creates new GPT geom object and this objects writes PMBR and its metadata to the provider. -- 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
