Re: 20220519 snapshot: loader fails to find bootable partition of zfs-root system
On Mon, May 23, 2022 at 8:40 PM Yasuhiro Kimura wrote: > > Hello, > > I made clean install of zfs-root 14-CURRENT amd64 system with install > image of 20220519 snapshop. After installation completed and system is > rebooted, boot fails as loader fails to find bootable partition as > following. > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220519snapshot.png > > If I use 20220512 snapshop instead, then system starts up > successfully. You need a loader with commit 9cd45772a44f268ccb3e20caf7f3f764f6b5e1a1 to deal with the latest OpenZFS. Regards, Navdeep
Re: [openzfs] r365058 arm64 uefi boot fails with "unknown filesystem" after launching kernel
Load cryptodev manually from the loader to boot and then add cryptodev_load="YES" to your loader.conf. Regards, Navdeep On 9/2/20 1:58 PM, Dave Cottlehuber wrote: > hi Matt, Ryan > > Something goes awry after loading kernel & zfs drivers, at point of mounting > the root filesystem from boot env - unknown filesystem. > > Running ? to show available fs doesn't show zfs here, but as we loaded kernel > already from zfs this is confusing. > > Any ideas? > > mountroot> ? > List of GEOM managed disk devices: > da1 ufs/FreeBSD_Install ufsid/5f3524aa78541663 > da0s2 > da0p1 > da0 > gpt/zfs0 > gpt/swap0 > msdosfs/EFISYS > gpt/efiboot0 > ada0p3 > ada0p2 ada0p1 ada0 > > Additionally at this point, it doesn't appear to be possible to boot/mount > from the previous boot environment, as zfs.ko etc is already loaded, I'm not > sure if I can set this prior with `loaddev` or similar. > > full dmesg/logs here - https://dpaste.org/iwRd , trimmed below. > > svn path=/head/; revision=365058 , commit 52a2c0f > > Consoles: EFI console > Reading loader env vars from /efi/freebsd/loader.env > Setting currdev to disk1p1: > FreeBSD/arm64 EFI loader, Revision 1.1 > >Command line arguments: loader.efi >Image base: 0x9fe6d3 >EFI version: 2.70 >EFI Firmware: American Megatrends (rev 5.13) >Console: efi (0x2000) >Load Path: \EFI\FreeBSD\loader.efi >Load Device: > PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(1,GPT,BE9634BF-D684-11EA-B300-001B21E07D7B,0x28,0x64000) >BootCurrent: 0001 >BootOrder: 0001[*] 0004 001b 001f 001a 000e 0003 0005 0006 0007 001c > 001d 001e >BootInfo Path: > HD(1,GPT,BE9634BF-D684-11EA-B300-001B21E07D7B,0x28,0x64000)/\EFI\refind\refind_aa64.efi > Ignoring Boot0001: Only one DP found > Trying ESP: > PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(1,GPT,BE9634BF-D684-11EA-B300-001B21E07D7B,0x28,0x64000) > Setting currdev to disk1p1: > Trying: > PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(2,GPT,BE9A1581-D684-11EA-B300-001B21E07D7B,0x64800,0x280) > Setting currdev to disk1p2: > Trying: > PciRoot(0xFF)/Pci(0x1,0x0)/Sata(0x0,0x,0x0)/HD(3,GPT,BEA23FFC-D684-11EA-B300-001B21E07D7B,0x2864800,0x355DE800) > Setting currdev to zfs:zroot/ROOT/13.0-CURRENT-20200901.193810: > Loading /boot/defaults/loader.conf > Loading /boot/defaults/loader.conf > Loading /boot/device.hints > Loading /boot/loader.conf > Loading /boot/loader.conf.local > Loading kernel... > /boot/kernel/kernel text=0x2a8 text=0x70 text=0x1e7a6c data=0x196b80 > data=0x0+0x3a378e syms=[0x8+0x165978+0x8+0x158936] > Loading configured modules... > /boot/kernel/tmpfs.ko text=0x4421 text=0x8fec data=0x1110+0x18 > syms=[0x8+0x1f68+0x8+0x13df] > /boot/kernel/xz.ko text=0x850 text=0x22d0 data=0x268+0x400 > syms=[0x8+0x870+0x8+0x412] > /boot/kernel/linuxkpi.ko text=0x709d text=0x13070 data=0x1970+0x750 > syms=[0x8+0x5a48+0x8+0x3dfb] > /boot/entropy size=0x1000 > /etc/hostid size=0x25 > /boot/kernel/mlx5en.ko text=0x19b35 text=0x11a48 data=0x26d8+0x8 > syms=[0x8+0x32e8+0x8+0x21ae] > /boot/kernel/mlx5.ko text=0xc369 text=0x23e24 data=0x1b50+0x94 > syms=[0x8+0x5100+0x8+0x3c65] > /boot/kernel/fusefs.ko text=0x8236 text=0xcb48 data=0x3420+0x68 > syms=[0x8+0x4350+0x8+0x4894] > /boot/kernel/opensolaris.ko text=0x12c3 text=0x94c data=0x468+0x6830 > syms=[0x8+0x1050+0x8+0x8bb] > /boot/kernel/mlxfw.ko text=0xed2 text=0x167c data=0x258 > syms=[0x8+0x750+0x8+0x409] > /boot/kernel/zfs.ko text=0xa3e88 text=0x1c8828 data=0x25908+0x158990 > syms=[0x8+0x2fa48+0x8+0x29ff3] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > No valid device tree blob found! > WARNING! Trying to fire up the kernel, but no device tree blob found! > EFI framebuffer information: > addr, size 0x43000, 0x1d4c00 > dimensions 800 x 600 > stride 800 > masks 0x00ff, 0xff00, 0x00ff, 0xff00 > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2020 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT r365058+d8f4c1a833bf-c271116(master) GENERIC arm64 > FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git > llvmorg-11.0.0-rc1-47-gff47911ddfc) > WARNING: WITNESS option enabled, expect reduced performance. > VT(efifb): resolution 800x600 > module firmware already present! > KLD file zfs.ko is missing dependencies > module_register: cannot register tmpfs from kernel; already loaded from > tmpfs.ko > Module tmpfs failed to register: 17 > real memory = 137167400960 (130813 MB) > avail memory = 133608034304 (127418 MB) > FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs > random: unblocking device. > ... > ada0 at ahcich0
Re: Compiling MOD_CC into kernel (TCP congestion control)?
On Sat, Apr 25, 2020 at 07:28:54PM +0200, Hartmann, O. wrote: > On a firewall/router project of ours I try to experiment with several > options/algorithms for mod_cc(4). I don't mean to sidetrack this thread but can you elaborate a bit? If it's a firewall/router then the TCP congestion control algorithm shouldn't really matter given that connections don't terminate on this device. Regards, Navdeep ___ 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: -CURRENT fatal trap cause by cxgbe module
I'm not able to reproduce this. I tried a test kernel built with "device cxgbe" and had if_cxgbe_load="YES" in loader.conf and the system came up just fine. Regards, Navdeep On 3/1/20 8:07 PM, Dustin Marquess wrote: > So I've been fighting with any current from the last month or so > instantly crashing when I boot it. I did notice that kernels in the > various snapshot images were working, however, so I was trying to > figure out why. At first I thought it was because I had INVARIANTS > and such disabled, but no, I finally figured it out. > > I've had in my /boot/loader.conf for a while now: > > if_cxgbe_load="YES" > > I guess since the stock installer kernels don't have cxgbe enabled by > default. I added "device cxgbe" to my kernels a while ago. Normally > the kernel would give some error about the module already being loaded > or something and just continue. As of last month or so, however, > instead it just crashes: > > FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git > c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x8 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80622931 > stack pointer = 0x28:0x8241c9a0 > frame pointer = 0x28:0x8241c9e0 > 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 0x8241c600 > vpanic() at vpanic+0x18a/frame 0x8241c660 > panic() at panic+0x43/frame 0x8241c6c0 > trap_fatal() at trap_fatal+0x386/frame 0x8241c720 > trap_pfault() at trap_pfault+0x99/frame 0x8241c7a0 > trap() at trap+0x4e9/frame 0x8241c8d0 > calltrap() at calltrap+0x8/frame 0x8241c8d0 > --- trap 0xc, rip = 0x80622931, rsp = 0x8241c9a0, rbp > = 0x8241c9e0 --- > malloc() at malloc+0x51/frame 0x8241c9e0 > sysctl_handle_string() at sysctl_handle_string+0x12d/frame 0x8241ca20 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0xa2/frame > 0x8241ca70 > sysctl_register_oid() at sysctl_register_oid+0x54c/frame 0x8241cd80 > sysctl_register_all() at sysctl_register_all+0x88/frame 0x8241cda0 > mi_startup() at mi_startup+0xf2/frame 0x8241cdf0 > btext() at btext+0x2c > KDB: enter: panic > [ thread pid 0 tid 0 ] > Stopped at kdb_enter+0x37: movq$0,0xa5f4a6(%rip) > db> > > If I take the if_cxgbe_load out, however, it boots fine. > > Thanks! > -Dustin > ___ > 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" > ___ 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: > r353680: multiuser crash due to: m_getzone: Inavlid cluster size 0
This is 241403 in bugzilla. On Wed, Oct 23, 2019, 12:57 AM O. Hartmann wrote: > The last known good update of CURRENT on a Fujitsu Primergy RX2530-M5 > (only one > of two sockets equipted, 64 GB RAM) was October, 17th, 2019 before 15 > o'clock, > I suppose that was r353680 that time. Today's update to r353881 resulted > in an > immediate crash when the network (igb0-igb3, two built-in i350 NICs and two > i350 NICs placed on a i350-T2 server adapter) comes up, just when rc > scripts > configure the NIC's. > > Last message I see is something like m_getzone: Inavlid cluster size 0 and > "dubugnet" or similar. Since the crash wrecked the installation (it seems > after > updating, the UFS filesystem received, as so often, inconsistencies, so I > can > not start vi or other applications after a full fsck -yf on all partitons, > those programs fail with some serious trap, stating that ELF is corrupt, I > can't remember the exact message). We do not have debugging facilities > enabled > on that kernel suite, so I can not provide more proper informations. > > For emergency rescue we downloaded the latest CURRENT memstick image, > FreeBSD-13.0-CURRENT-amd64-20191018-r353709-memstick.img dated Oct., 18th, > which > also shows the bug described above. > > It seems that I have to go back to memimage > FreeBSD-13.0-CURRENT-amd64-20191011-r353427-memstick.img which dates to > 11th > October 2019. > Since the crash resulted in a serious damage of the base filesystem and the > installation, I need to copy first the installation tarballs from the > install > memstick into place and try then to rebuild the system with sources up to > the > version which is deemed working. The I'll report, hopefully, more > information. > > Kind regards, > oh > > Addendum: > > r353680 works > r353709 doesn't work > > > [...] > /etc # more /var/crash/info.last > Dump header from device: /dev/da0p2 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 2952835072 > Blocksize: 512 > Compression: none > Dumptime: Tue Oct 22 12:13:19 2019 > Hostname: wotan.lan101.bundesimmobilien.intern > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 13.0-CURRENT #11 r353877: Tue Oct 22 11:02:32 > CEST > 2019 root@:/usr/obj/usr/src/amd64.amd64/sys/WOTAN > Panic String: m_getzone: invalid cluster size 0 > Dump Parity: 2027469319 > Bounds: 0 > Dump Status: good > [...] > > [...] > > # more /var/crash/core.txt.0 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > > > [...] > > > [...] > ---<>--- > Copyright (c) 1992-2019 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT #14 r353680: Wed Oct 23 08:50:04 CEST 2019 > root@wotan.lan101.bundesimmobilien.intern > :/usr/obj/usr/src/amd64.amd64/sys/WOTAN > amd64 FreeBSD clang version 9.0.0 (tags/RELEASE_900/final 372316) (based on > LLVM 9.0.0) VT(efifb): resolution 1280x1024 > CPU microcode: no matching update found > CPU: Intel(R) Xeon(R) Gold 5217 CPU @ 3.00GHz (2993.05-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x50657 Family=0x6 Model=0x55 Stepping=7 > > Features=0xbfebfbff > > Features2=0x7ffefbff > AMD Features=0x2c100800 > AMD Features2=0x121 > Structured Extended > > Features=0xd39b > Structured Extended Features2=0x808 Structured Extended > Features3=0xbc000400 XSAVE > Features=0xf > IA32_ARCH_CAPS=0x2b VT-x: > PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, > performance > statistics real memory = 68719476736 (65536 MB) > avail memory = 66361274368 (63287 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs > FreeBSD/SMP: 1 package(s) x 8 core(s) x 2 hardware threads > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > random: unblocking device. > Security policy loaded: MAC/ntpd (mac_ntpd) > ioapic0 irqs 0-23 > ioapic1 irqs 24-31 > ioapic2 irqs 32-39 > ioapic3 irqs 40-47 > ioapic4 irqs 48-55 > Launching APs: 1 13 5 12 9 14 8 7 10 6 11 15 3 4 2 > Timecounter "TSC-low" frequency 1496523352 Hz quality 1000 > random: entropy device external interface > kbd0 at kbdmux0 > [...] > ___ > 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: netmap on cxgb (Chelsio T3) — panic on transmit
On 11/22/18 7:30 AM, Lev Serebryakov wrote: > > I've obtained Chelsio T3 for my "network lab". It works with cxgb > driver well, but when I try to use Netmap's pkt-gen on it it crashes > system immediately with such message: > > panic: trying to coalesce 9 packets in to one WR > > I've turned all checksums, lro and tso off, but it doesn't help. > > Do I have any chances to get netmap supported (maybe, not very > efficient) on this NIC? > The T3 is a very old chip that has been EoL'd for some time and it's not likely to get native netmap support. Your panic must be while using netmap's emulation mode on top of cxgb. Try modifying check_pkt_coalesce() in the driver to always return 0 and see if that avoids the panic. Don't expect much performance-wise even if that works. Regards, Navdeep ___ 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: 10G performance regression / difference cxl and ix RELENG11 vs HEAD
On 10/12/18 9:52 AM, Navdeep Parhar wrote: > The number of retries (the "Retr" column) should have been 0 in a retransmits, not retries. ___ 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: 10G performance regression / difference cxl and ix RELENG11 vs HEAD
On 10/12/18 8:37 AM, Mike Tancsa wrote: > I was doing a quick iperf test with r339328 GENERIC-NODEBUG amd64, and > noticed I can no longer saturate a 10G nic with iperf3. I tried first > with the ix adapter, but was not sure if it was the driver or not. I > tried as well with a Chelsio and got similar numbers. > > # iperf3 -c 192.168.242.3 > Connecting to host 192.168.242.3, port 5201 > [ 5] local 192.168.242.2 port 50474 connected to 192.168.242.3 port 5201 > [ ID] Interval Transfer Bitrate Retr Cwnd > [ 5] 0.00-1.00 sec 997 MBytes 8.36 Gbits/sec 717 175 > KBytes > [ 5] 1.00-2.00 sec 975 MBytes 8.18 Gbits/sec 668 41.1 > KBytes > [ 5] 2.00-3.00 sec 880 MBytes 7.38 Gbits/sec 846 25.6 > KBytes > [ 5] 3.00-4.00 sec 523 MBytes 4.39 Gbits/sec 802 59.8 > KBytes > [ 5] 4.00-5.00 sec 520 MBytes 4.36 Gbits/sec 882 48.4 > KBytes > [ 5] 5.00-6.00 sec 543 MBytes 4.55 Gbits/sec 838 56.9 > KBytes > [ 5] 6.00-7.00 sec 556 MBytes 4.66 Gbits/sec 850 11.4 > KBytes > [ 5] 7.00-8.00 sec 538 MBytes 4.51 Gbits/sec 795 39.9 > KBytes > [ 5] 8.00-9.00 sec 540 MBytes 4.53 Gbits/sec 853 57.0 > KBytes > [ 5] 9.00-10.00 sec 503 MBytes 4.22 Gbits/sec 814 59.8 > KBytes > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec 8065 > sender > [ 5] 0.00-10.00 sec 6.42 GBytes 5.52 Gbits/sec > receiver The number of retries (the "Retr" column) should have been 0 in a controlled test like this. Is this the default stack with all default parameters or have you tuned TCP and/or sockets in any way? Regards, Navdeep ___ 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: TCP server app performance
On 8/12/18 9:50 AM, Honda Michio wrote: > Hi, > > I'm measuring TCP server app performance using my toy web server. > It just accept TCP connections and responds back HTTP OK to the clients. > It monitors sockets using kqueue, and processes each ready descriptor using > a pair of read() and write(). (in more detail, it's > https://github.com/micchie/netmap/tree/paste/apps/phttpd) > > Using 100 persistent TCP connections (the client sends 44 B HTTP GET and > the server responds with 151 B of HTTP OK) and a single CPU core, I only > get 152K requests per second, which is 2.5x slower than Linux that runs the > same app (except that it uses epoll instead of kqueue). > I cannot justify this by myself. Does anybody has some intuition about how > much FreeBSD would get with such workloads? > I tried disabling TCP delayed ack and changing interrupt rates, but no > significant difference was observed. > > I use FreeBSD-CURRENT with GENERIC-NODEBUG (git commit hash: 3015145c3aa4b). > For hardware, the server has Xeon Silver 4110 and Intel X540 NIC (activate > only a single queue as I test with a single CPU core). All the offloadings > are disabled. I hope hw L3/L4 checksumming is still on? Are your results similar to what you get with 100 (same number as your test clients) netperf's doing TCP_RR on this setup, or wildly different? Regards, Navdeep ___ 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: buildkernel broken on if_ixl when EVDEV is enabled
On 06/22/18 10:38, Navdeep Parhar wrote: > On 06/22/18 10:25, Pete Wright wrote: >> >> >> On 06/21/2018 20:47, Danilo Egêa Gondolfo wrote: >>> Hi, >>> >>> check if you have 'options IXL_IW' in your kernel conf. It's removed >>> from GENERIC. I had the same problem here with my customized conf. >> >> ah - that was totally it i think. i was lazy and just copied GENERIC to >> GENERIC-EVDEV so it got of sync. i've now re-created my EVDEV config to >> just include GENERIC. > > You can avoid your kernconf going out of sync by including GENERIC in it > and then adding just your customizations. oops I missed the last sentence in your email. ___ 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: buildkernel broken on if_ixl when EVDEV is enabled
On 06/22/18 10:25, Pete Wright wrote: > > > On 06/21/2018 20:47, Danilo Egêa Gondolfo wrote: >> Hi, >> >> check if you have 'options IXL_IW' in your kernel conf. It's removed >> from GENERIC. I had the same problem here with my customized conf. > > ah - that was totally it i think. i was lazy and just copied GENERIC to > GENERIC-EVDEV so it got of sync. i've now re-created my EVDEV config to > just include GENERIC. You can avoid your kernconf going out of sync by including GENERIC in it and then adding just your customizations. include GENERIC ident GENERIC-EVDEV options EVDEV_SUPPORT device evdev Regards, Navdeep ___ 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: Building Current
On Sat, Mar 04, 2017 at 03:46:20PM -0500, Roberto Rodriguez Jr wrote: > What tools can I use to make the building a little faster? > The src tree supports incremental builds. You'll need to load the filemon module and add WITH_META_MODE=yes in /etc/src-env.conf to use it. See the WITH_META_MODE bits in src.conf(5), build(7) for some more details. It would be nice to have WITH_META_MODE as default but that's a separate discussion. Regards, Navdeep ___ 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: How to load kernel module automatic?
On Tue, Dec 06, 2016 at 05:43:38PM +0300, Slawa Olhovchenkov wrote:
> On Tue, Dec 06, 2016 at 06:41:14AM -0800, Navdeep Parhar wrote:
>
> > On Tue, Dec 06, 2016 at 05:34:56PM +0300, Slawa Olhovchenkov wrote:
> > > On Tue, Dec 06, 2016 at 06:25:44AM -0800, Navdeep Parhar wrote:
> > >
> > > > On Tue, Dec 06, 2016 at 02:47:15PM +0300, Slawa Olhovchenkov wrote:
> > > > > Now I am try to update fw in chelsio card.
> > > > > Firmware can't be updated if card was running (interface go to UP).
> > > > > I am try to unload if_cxgbe module, check module unloaded... and after
> > > > > short time see module loaded again!
> > > > > How is this possible?
> > > >
> > > > Something is running "ifconfig cxgbe|cxl|cc" on your system. ifconfig
> > > > can figure out the name of the module from the name of the ifnet and
> > > > will kldload it if it isn't in the kernel already.
> > >
> > > What is 'something'?
> >
> > A script that's running via devd or some other mechanism.
>
> Its not clear to me what exact event cause devd start such script.
Doesn't have to be devd. Could be any automated script running
ifconfig. Leave this running and see if ifconfig is ever called with
(cxgbe|cxl|cc) as parameter. If it is then that's what's loading
cxgbe(4) automatically.
dtrace -n 'proc:::exec-success /execname == "ifconfig"/
{trace(curpsinfo->pr_psargs);}
Regards,
Navdeep
___
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: How to load kernel module automatic?
On Tue, Dec 06, 2016 at 05:34:56PM +0300, Slawa Olhovchenkov wrote: > On Tue, Dec 06, 2016 at 06:25:44AM -0800, Navdeep Parhar wrote: > > > On Tue, Dec 06, 2016 at 02:47:15PM +0300, Slawa Olhovchenkov wrote: > > > Now I am try to update fw in chelsio card. > > > Firmware can't be updated if card was running (interface go to UP). > > > I am try to unload if_cxgbe module, check module unloaded... and after > > > short time see module loaded again! > > > How is this possible? > > > > Something is running "ifconfig cxgbe|cxl|cc" on your system. ifconfig > > can figure out the name of the module from the name of the ifnet and > > will kldload it if it isn't in the kernel already. > > What is 'something'? A script that's running via devd or some other mechanism. Regards, Navdeep ___ 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: How to load kernel module automatic?
On Tue, Dec 06, 2016 at 02:47:15PM +0300, Slawa Olhovchenkov wrote: > Now I am try to update fw in chelsio card. > Firmware can't be updated if card was running (interface go to UP). > I am try to unload if_cxgbe module, check module unloaded... and after > short time see module loaded again! > How is this possible? Something is running "ifconfig cxgbe|cxl|cc" on your system. ifconfig can figure out the name of the module from the name of the ifnet and will kldload it if it isn't in the kernel already. Regards, Navdeep ___ 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: build fails post SVN r304026
On Sat, Aug 13, 2016 at 08:30:09PM +, Rick Macklem wrote: > Lev Serebryakov wrote: > >On 13.08.2016 16:54, Michael Butler wrote: > > > >> Is anyone else seeing this? > > Yes, I've posted message to fs@, as it is r304026 for sure (and author > >was CC:ed too). > Should be fixed now. Sorry about the breakage. I didn't realize the old > nfsstat.c wouldn't build with the kernel source patch. (The old nfsstat > binary does still work, as required to avoid a POLA violation.) > > Anyhow, the changes to nfsstat.c are now committed to head. I still see errors in nfsstat during buildworld (this is r304065): Building /usr/obj/usr/src/usr.bin/nfsstat/nfsstat.full nfsstat.o: In function `compute_new_stats': /usr/src/usr.bin/nfsstat/nfsstat.c:506: undefined reference to `devstat_compute_etime' /usr/src/usr.bin/nfsstat/nfsstat.c:532: undefined reference to `devstat_compute_etime' /usr/src/usr.bin/nfsstat/nfsstat.c:506: undefined reference to `devstat_compute_etime' /usr/src/usr.bin/nfsstat/nfsstat.c:532: undefined reference to `devstat_compute_etime' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Regards, Navdeep ___ 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: 11.0 -r300944 build*KERNEL* via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions'; cxgbe has an issue too
On Tue, May 31, 2016 at 10:49:29PM -0700, Mark Millard wrote: > On 2016-May-31, at 10:31 PM, Mark Millard wrote: > > > If the offending declaration in cxgb_listen.c is commented out (or removed) > there is a "next problem" but for cxgbe: > > > --- all_subdir_cxgbe/tom --- > > /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c: In > > function 'do_pass_accept_req': > > /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:640:1: > > warning: inlining failed in call to 'release_synqe': call is unlikely and > > code size would grow [-Winline] Can you try removing the "inline" at line 639 in t4_listen.c and see if that makes a difference? Regards, Navdeep ___ 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: kgdb ported to devel/gdb
On Fri, Oct 02, 2015 at 09:19:13AM +0300, Andriy Gapon wrote: > On 01/09/2015 00:32, John Baldwin wrote: > > Over the past several months I have ported kgdb to the version of gdb in > > ports. > > I have a pending patch to the gdb port to add fork following, but once that > > is > > done (and possibly after updating to 7.10) I will try to add my existing > > work > > as a KGDB option on the port. Until such time, you can try the newer kgdb > > by > > checking out my branch from git. > > > > Here's my cheat sheet on how to build the newer kgdb. Note that if you > > build > > a world with my cross-libkvm patches you should get a kgdb that can debug > > i386 cores on amd64 and vice versa. > > > > All of the targets that the native devel/gdb support have their backends > > ported (so x86, sparc64, powerpc and powerpc64). I have not yet ported > > arm or mips since those don't work for userland yet in upstream gdb. I > > have only compiled non-x86 backends. Testing of the new kgdb on sparc64 > > and powerpc would be appreciated. > > > > Steps: > > > > % git clone https://github.com/bsdjhb/gdb.git > > % git checkout freebsd-7.9.1-kgdb > > % fetch http://www.freebsd.org/~jhb/gdb/build > > % pkg install devel/gdb > > > > # Having gdb installed will mean you get the python bindings in the right > > # place. > > > > % pkg install gmake > > > > # I think this is the only build tool you need? > > > > % ./build > > % cd obj > > > > # Replace 'obj' with 'obj.' for all but amd64 > > > > % gmake > > > > # ... wait > > > > You will now have a binary at 'obj/gdb/kgdb'. I just run it from my obj > > tree currently when testing. Once it becomes part of the port it will get > > installed as /usr/local/bin/kgdb791 or some such. > > John, > > first of all, thank you very much for this! > > I followed your instructions substituting freebsd-7.10-kgdb for > freebsd-7.9.1-kgdb branch (devel/gdb is also at version 7.10) and the build > process worked just fine. > However, when I try to use the new kgdb it works, but I get some annoying > diagnostics: > > ... Andriy, The patch is also available in D3727. I downloaded the raw diff from there, applied it to $PORTS/devel/gdb, and built it as a port (with the KGDB support option enabled of course). Everything works. Can you try that? https://reviews.freebsd.org/D3727 Regards, Navdeep ___ 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"
panic in sysctl code in recent head
A kernel built from head as of today panics with this on loading a module. Does anyone else see this too? panic: sleepq_add: td 0xf8000e7f89e0 to sleep on wchan 0x824056c8 with sleeping prohibited cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2e/frame 0xfe02383ebe40 kdb_backtrace() at kdb_backtrace+0x58/frame 0xfe02383ebf10 vpanic() at vpanic+0x25e/frame 0xfe02383ebfe0 kassert_panic() at kassert_panic+0xcc/frame 0xfe02383ec070 sleepq_add() at sleepq_add+0x1ed/frame 0xfe02383ec0e0 _sx_xlock_hard() at _sx_xlock_hard+0xa88/frame 0xfe02383ec320 __sx_xlock() at __sx_xlock+0x77/frame 0xfe02383ec380 _sx_xlock() at _sx_xlock+0x170/frame 0xfe02383ec3f0 _rm_rlock_hard() at _rm_rlock_hard+0x323/frame 0xfe02383ec490 _rm_rlock() at _rm_rlock+0x173/frame 0xfe02383ec4e0 _rm_rlock_debug() at _rm_rlock_debug+0x284/frame 0xfe02383ec560 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x148/frame 0xfe02383ec5b0 sysctl_root() at sysctl_root+0x38d/frame 0xfe02383ec660 userland_sysctl() at userland_sysctl+0x315/frame 0xfe02383ec7a0 sys___sysctl() at sys___sysctl+0xfc/frame 0xfe02383ec8a0 syscallenter() at syscallenter+0x521/frame 0xfe02383ec980 amd64_syscall() at amd64_syscall+0x2a/frame 0xfe02383ecab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe02383ecab0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8011b02ba, rsp = 0x7fffda28, rbp = 0x7fffda60 --- KDB: enter: panic ___ 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: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)
On Sun, Jul 19, 2015 at 11:05:48PM -0700, Don Lewis wrote: > On 19 Jul, O'Connor, Daniel wrote: > > > >> On 19 Jul 2015, at 02:56, Simon J. Gerraty wrote: > >> > >> O'Connor, Daniel wrote: > >>> However, Crochet _does_ build on the NFS client _and_ when the > >>> source tree isn't in /usr/src which makes this issue very strange > >>> :-/ > >> > >> I've seen similar errors in rescue... (no NFS) though I cannot > >> quite recall the cause other than it seems very sensitive > >> to MAKEOBJDIRPREFIX value. > > > > Yeah the subject is wrong (I just updated it). > > > > I just did a build like so and it worked.. > > env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld > > > > But this did not.. > > make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64 > > > > So, it seems MAKEOBJDIRPREFIX only works as an environmental variable > > - I wonder if there is a way the make system can be changed to warn > > about that? > > At least it is documented in /usr/share/mk/bsd.obj.mk: > > # MAKEOBJDIRPREFIX Specifies somewhere other than /usr/obj to root the object > # tree. Note: MAKEOBJDIRPREFIX is an *environment* variable > # and works properly only if set as an environment variable, > # not as a global or command line variable! > # > # E.g. use `env MAKEOBJDIRPREFIX=/somewhere/obj make' > > Not the most obvious place to look ... It is documented in build(7) too: MAKEOBJDIRPREFIX Defines the prefix for directory names in the tree of built objects. Defaults to /usr/obj if not defined. This variable should only be set in the environment and not via /etc/make.conf or the command line. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]
On 08/20/14 12:25, Hans Petter Selasky wrote: On 08/20/14 20:44, Navdeep Parhar wrote: On 08/20/14 00:34, Hans Petter Selasky wrote: Hi, A month has passed since the last e-mail on this topic, and in the meanwhile some new patches have been created and tested: Basically the approach has been changed a little bit: - The creation of hardware transmit rings has been made independent of the TCP stack. This allows firewall applications to forward traffic into hardware transmit rings aswell, and not only native TCP applications. This should be one more reason to get the feature into the kernel. - A hardware transmit ring basically can have two modes: FIXED-RATE or AUTOMATIC-RATE. In the fixed rate mode all traffic is sent at a fixed bytes per second rate. In the automatic mode you can configure a time after which the TX queue must be empty. The hardware driver uses this to configure the actual rate. In automatic mode you can also set an upper and lower transmit rate limit. - The MBUF has got a new field in the packet header: "txringid" - IOCTLs for TCP v4 and v6 sockets has been updated to allow setting of the "txringid" field in the mbuf. The current patch [see attachment] should be much simpler and less intrusive than the previous one. Any comments ? Here are some thoughts. The first two bullets cover relatively minor issues, the rest are more important. - All of the mbuf pkthdr fields today have the same meaning no matter what the context. It is not clear what txringid's global meaning is. Is it even possible for driver foo to interpret it the same way as driver bar? What if the number of rings are different, or if the ring at the particular index for foo is setup differently than the ring at that same index for bar? You are attempting to influence the driver's txq selection and traditionally the mbuf's flowid has been used for this purpose. Have you considered allowing the user to set the flowid directly? And mark it as such via a new rsstype so the kernel will leave it alone. Hi, At work so to speak, we have tried to make a simple approach that will not break existing code, without trying to optimise the possibilities and reduce memory footprint. - uint32_t -> m_flowid_t is plain gratuitous. Now we need to include mbuf.h in more places just to get this definition. What's the advantage of this? style(9) isn't too fond of typedefs either. Also, drivers *do* need to know the width of the flowid. At least lagg(4) looks at the high bits of the flowid (see flowid_shift in lagg). How high it can go depends on the width of the flowid. The flowid should be typedef'ed. Else how can you know its type passing flowid along function arguments and so on? It's just a simple 32 bit unsigned int and all drivers know exactly what it is. I don't think we need type checking for trivial stuff like this. We trust code to do the right thing and that's the correct tradeoff here, in my opinion. Or else we'd end up with errno_t, fd_t, etc. and programming in C would not be fun anymore. Here's a hyperbolic example: errno_t socket(domain_t domain, socktype_t type, protocol_t protocol); (oops, it returns an int -1 or 0 so errno_t is not strictly correct, but you get my point). - Interfaces can come and go, routes can change, and so the relationship between an inpcb and txringid is not stable at all. What happens when the outbound route for an inpcb changes? This is managed separately by a daemon or such. The problem about using the "inpcb" approach which you are suggesting, is that you limit the rate control feature to traffic which is bound by sockets. Can your way of doing rate control be useful to non-socket based firewall applications, for example? You also assume a 1:1 mapping between "inpcb" and the flowID, right. What about M:N mappings, where multiple streams should share the same flowID, because it makes more sense? You're right that an inpcb based scheme won't work for non-socket based firewall. inpcb represents an endpoint, almost always with an associated socket, and it mostly has a 1:1 relation with an n-tuple (SO_LISTEN and UDP sockets with no default destination are notable exceptions). If you're talking of non-socket based firewalls, then where is the inpcb coming from? Firewalls typically keep their own state for the n-tuples that they are interested in. It almost seems like you need a n-tuple -> rate_limit mapping scheme instead of inpcb -> rate_limit. Regards, Navdeep - The in_ratectlreq structure that you propose is inadequate in its current form. For example, cxgbe's hardware can do rate limiting on a per-ring as well as per-connection basis, and it allows for pps, bandwidth, or min-max limits. I think this is the critical piece that we NIC maintainers must agre
Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections]
On 08/20/14 00:34, Hans Petter Selasky wrote: Hi, A month has passed since the last e-mail on this topic, and in the meanwhile some new patches have been created and tested: Basically the approach has been changed a little bit: - The creation of hardware transmit rings has been made independent of the TCP stack. This allows firewall applications to forward traffic into hardware transmit rings aswell, and not only native TCP applications. This should be one more reason to get the feature into the kernel. - A hardware transmit ring basically can have two modes: FIXED-RATE or AUTOMATIC-RATE. In the fixed rate mode all traffic is sent at a fixed bytes per second rate. In the automatic mode you can configure a time after which the TX queue must be empty. The hardware driver uses this to configure the actual rate. In automatic mode you can also set an upper and lower transmit rate limit. - The MBUF has got a new field in the packet header: "txringid" - IOCTLs for TCP v4 and v6 sockets has been updated to allow setting of the "txringid" field in the mbuf. The current patch [see attachment] should be much simpler and less intrusive than the previous one. Any comments ? Here are some thoughts. The first two bullets cover relatively minor issues, the rest are more important. - All of the mbuf pkthdr fields today have the same meaning no matter what the context. It is not clear what txringid's global meaning is. Is it even possible for driver foo to interpret it the same way as driver bar? What if the number of rings are different, or if the ring at the particular index for foo is setup differently than the ring at that same index for bar? You are attempting to influence the driver's txq selection and traditionally the mbuf's flowid has been used for this purpose. Have you considered allowing the user to set the flowid directly? And mark it as such via a new rsstype so the kernel will leave it alone. - uint32_t -> m_flowid_t is plain gratuitous. Now we need to include mbuf.h in more places just to get this definition. What's the advantage of this? style(9) isn't too fond of typedefs either. Also, drivers *do* need to know the width of the flowid. At least lagg(4) looks at the high bits of the flowid (see flowid_shift in lagg). How high it can go depends on the width of the flowid. - Interfaces can come and go, routes can change, and so the relationship between an inpcb and txringid is not stable at all. What happens when the outbound route for an inpcb changes? - The in_ratectlreq structure that you propose is inadequate in its current form. For example, cxgbe's hardware can do rate limiting on a per-ring as well as per-connection basis, and it allows for pps, bandwidth, or min-max limits. I think this is the critical piece that we NIC maintainers must agree on before any code hits the core kernel: how to express a rate-limit policy in a standard way and allow for hardware assistance opportunistically. ipfw(4)'s dummynet is probably interested in this part too, so it's great that Luigi is paying attention to this thread. - The RATECTL ioctls deal with in_ratectlreq so we need to standardize the ratectlreq structure before these ioctls can be considered generic ifnet ioctls. This is the reason cxgbetool (and not ifconfig) has a private ioctl to frob cxgbe's per-queue rate-limiters. I did not want to add ifnet ioctls that in reality were cxgbe only. Ditto for i2c ioctls. Now we have multiple drivers with i2c and melifaro@ is doing the right thing by promoting these private ioctls to a standard ifnet ioctl. Have you considered a private mlxtool as a stop gap measure? To summarize my take on all of this: we need a standard ratectlreq structure, a standard way to associate an inpcb with one, and a standard way to pass on this info to if_transmit. After all this is in place we could even have a dummynet-ish software layer that implements rate limiters when the underlying hardware offers no assistance. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On 07/17/14 13:12, Adrian Chadd wrote: > On 17 July 2014 13:03, Alberto Mijares wrote: >> On Thu, Jul 17, 2014 at 2:58 PM, Adrian Chadd wrote: >>> Hi! >>> >>> 3) The binary packages need to work out of the box >>> 4) .. which means, when you do things like pkg install apache, it >>> can't just be installed and not be enabled, because that's a bit of a >>> problem; >> >> >> No. Please NEVER do that! The user must be able to edit the files and >> start the service by himself. > > Cool, so what's the single line command needed to type in to start a > given package service? Aren't sysrc(8) and service(8) for this kind of stuff? ___ 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] Add support for changing the flow ID of TCP connections
On Wed, Jul 09, 2014 at 04:36:53PM +0200, Hans Petter Selasky wrote: > On 07/08/14 21:17, Navdeep Parhar wrote: ... > > > >I think we need to design this to be as generic as possible. I have > >quite a bit of code that does this stuff but I haven't pushed it > >upstream or even offered it for review (yet). > > > > Hi, > > When will the non hardware related patches be available for review? > I understand there are multiple ways to reach the same goal, and I > think it would be great if we could agree on a common API for > applications. Here is the kernel side of the patch: http://people.freebsd.org/~np/flow_pacing_kern.diff The registration parameters and the throttling parameters are probably cxgbe-centric, because that's what it was written for. We'll need to tidy up those structs certainly. And I'd like to add pps constraints to the throttling parameters (all it does is bandwidth right now). Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Add support for changing the flow ID of TCP connections
On 07/08/14 10:46, Hans Petter Selasky wrote: > Hi, > > I'm working on a new feature which will allow TCP connections to be > timing controlled by the ethernet hardware driver, actually the mlxen > driver. The main missing piece in the kernel is to allow the mbuf's > flowid value to be overwritten in "struct inpcb" once the connection is > established and to have a callback once the TCP connection is gone so > that the assigned "flowid" can be freed by the ethernet hardware driver. > > The "flowid" will be used to assign the outgoing data traffic of a > specific TCP connections to a hardware controlled queue, which in > advance contain certain parameters about the timing for the transmitted > packets. > > To be able to set the flowid I'm using existing functions in the kernel > TCP code to lookup the "inpcb" structure based on the 4-tuple, via the > "ifp->if_ioctl()" callback of the network adapter. I'm also registering > a function method table so that I get a callback when the TCP connection > is gone. > > A this point of development I would like to get some feedback from > FreeBSD network guys about my attached patch proposal. > > The motivation for this work is to have a more reliable TCP > transmissions typically for fixed-rate media content going some > distance. To illustrate this I will give you an example from the world > of VoIP, which is using UDP. When doing long-distance VoIP calls through > various unknown networks and routers it makes a very big difference if > you are sending data 20ms apart or 40ms apart, even at the exact same > rate. In the one case you might experience a bunch of packet drops, and > in the other case, everything is fine. Why? Because the number of > packets you send per second, and the timing is important. The goal is to > apply some timing rules for TCP, to increase the factor of successful > transmission, and to reduce the amount of data loss. For high throughput > applications we want to do this by means of hardware. > > > While at it I would like to "typedef" the flowid used by mbufs, "struct > inpcb" and many more places. Where would the right place be to put such > a definition? In "sys/mbuf.h"? > > > Comments are appreciated! I think we need to design this to be as generic as possible. I have quite a bit of code that does this stuff but I haven't pushed it upstream or even offered it for review (yet). cxgbe(4) hardware does throttling and traffic pacing too, but it's not limited to TCP, and it can do it per queue or per "flow" -- you can limit a tx queue or an individual flow to a packet-per-second limit or a bandwidth ceiling; this works for both plain NIC (TCP, UDP, whatever), as well as stateful TCP offload). For TCP (NIC or TOE) the chip can even rewrite the TCP timestamp to account for the extra time that the chip/driver held the packet because it was asked to slow down a flow. The per queue stuff is handled via a driver-specific tool (cxgbetool). For per-flow throttling my implementation adds a new sockopt (SO_TX_THROTTLE) that lets an application specify a throttle rate for a socket. The kernel allocates a "flow identifier" for each such socket and tcp_output (or udp_output, ..) will attach an mbuf tag containing this identifier and throttling parameters to each mbuf that it pushes out. Drivers for hardware that can throttle traffic look for this tag, the rest ignore it. - cxgbe(4) registers itself as a "flow throttling provider" with the kernel when it attaches to the chip. It tells the kernel how many flows it can handle and the range of rates it can handle. - setsockopt(SO_TX_THROTTLE, rate) makes the kernel allocate a unique identifier for the socket. This is *not* related to the RSS flowid at all. If a listening socket has SO_TX_THROTTLE, all its children will inherit the rate limiting parameters but will each get its own unique identifier. The setsockopt fails if there aren't any flow throttling providers registered, - tcp_output (and other proto_output) routines look for SO_TX_THROTTLE and attach extra metadata, in the form of a tag, to the outgoing frames. - cxgbe(4) reads this metadata and acts on it. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD iscsi target
On Wed, Jul 02, 2014 at 03:26:09PM +0400, Slawa Olhovchenkov wrote: > On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: > > > On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov wrote: > > > > > On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala wrote: > > > > > > > Hi. I've replied in private, but just for the record: > > > > > > > > On 0627T0927, Sreenivasa Honnur wrote: > > > > > Does freebsd iscsi target supports: > > > > > 1. ACL (access control lists) > > > > > > > > In 10-STABLE there is a way to control access based on initiator > > > > name and IP address. > > > > > > > > > 2. iSNS > > > > > > > > No; it's one of the iSCSI features that seem to only be used > > > > for marketing purposes :-) > > > > > > > > > 3. Multiple connections per session > > > > > > > > No; see above. > > > > > > I think this is help for 40G links. > > > > > > > I assume that you are looking at transfer of large amounts of data over 40G > > links. Assuming that tis is the case, yes, multiple connections per session > > Yes, this case. As I know, single transfer over 40G link limited by > 10G. This is not correct. A 40Gb link does not limit a single transfer to 10G. For example, on FreeBSD all common bandwidth benchmarks reach 40GbE line rate with a single TCP connection at mtu 1500. If a single transfer were limited to 10G you'd need 4 connections to get there. The physical signalling is over four lanes so it's easy to split a 40G link into four separate 10G links. But when running as a 40GbE (this is the usual case) the hardware will combine all the lanes into a single 40G data stream, and you get to use all of the bandwidth. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADS UP] enabling LLDB debugger by default on amd64
Any plans to get kernel debugging working? On 12/17/13 14:15, Ed Maste wrote: > The in-tree snapshot of LLDB is at a point where it's usable and > suitable for wider testing on amd64, and so I intend to enable it by > default in the near future. > > Further information on the FreeBSD port of LLDB is on the wiki, at > https://wiki.freebsd.org/lldb > > On my desktop LLDB added about 5 minutes to a buildworld and 80MB to > objdir (over a baseline of about an hour and 1.8GB). If you wish to > avoid building it, you can add 'WITHOUT_LLDB=' to src.conf. > > -Ed > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [net] protecting interfaces from races between control and data ?
On 08/05/13 09:15, Luigi Rizzo wrote: > On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote: > >> On 5 August 2013 07:59, Bryan Venteicher >> wrote: >> >>> What I've done in my drivers is: >>> * Lock the core mutex >>> * Clear IFF_DRV_RUNNING >>> * Lock/unlock each queue's lock >> >> .. and I think that's the only sane way of doing it. >> > > yeah, this was also the solution we had in mind, i was surprised > not find this pattern in the drivers i have looked at. > > Also there are drivers (chelsio ?) which do not seem to have locks on the > receive interrupt handlers ? This is correct. cxgbe(4) does not have any locks on rx, just a "state" for each rx queue that's maintained with atomic ops. Regards, Navdeep > > Does anyone know how linux copes with the same problem ? > > They seem to have an rtnl_lock() which is a global lock for all > configuration > of netdevices (would replace our per-interface 'core lock' above), > but i am totally unclear on how individual tx threads and interrupt handlers > acknowledge that they have read the change in status. > > cheers > luigi > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on sparc64/sparc64
On Thu, Jul 11, 2013 at 12:07:33AM -0700, Adrian Chadd wrote: > On 11 July 2013 00:05, Navdeep Parhar wrote: > > On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: > >> I don't get why this is dying. any ideas? > > > > Maybe because sparc64's ucontext.h is getting pulled in, and it has > > this: > > > > #define mc_flagsmc_global[0] > > Ugh, we should fix this. When did this happen? You tell me. I was just running cscope in my spare time ;-) ___ 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: [head tinderbox] failure on sparc64/sparc64
On Wed, Jul 10, 2013 at 10:38:47PM -0700, Adrian Chadd wrote: > I don't get why this is dying. any ideas? Maybe because sparc64's ucontext.h is getting pulled in, and it has this: #define mc_flagsmc_global[0] Regards, Navdeep > > > > adrian > > On 10 July 2013 21:18, FreeBSD Tinderbox wrote: > > TB --- 2013-07-11 02:56:02 - tinderbox 2.10 running on > > freebsd-current.sentex.ca > > TB --- 2013-07-11 02:56:02 - FreeBSD freebsd-current.sentex.ca > > 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 > > d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > > TB --- 2013-07-11 02:56:02 - starting HEAD tinderbox run for sparc64/sparc64 > > TB --- 2013-07-11 02:56:02 - cleaning the object tree > > TB --- 2013-07-11 02:56:56 - /usr/local/bin/svn stat /src > > TB --- 2013-07-11 02:57:06 - At svn revision 253161 > > TB --- 2013-07-11 02:57:07 - building world > > TB --- 2013-07-11 02:57:07 - CROSS_BUILD_TESTING=YES > > TB --- 2013-07-11 02:57:07 - MAKEOBJDIRPREFIX=/obj > > TB --- 2013-07-11 02:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2013-07-11 02:57:07 - SRCCONF=/dev/null > > TB --- 2013-07-11 02:57:07 - TARGET=sparc64 > > TB --- 2013-07-11 02:57:07 - TARGET_ARCH=sparc64 > > TB --- 2013-07-11 02:57:07 - TZ=UTC > > TB --- 2013-07-11 02:57:07 - __MAKE_CONF=/dev/null > > TB --- 2013-07-11 02:57:07 - cd /src > > TB --- 2013-07-11 02:57:07 - /usr/bin/make -B buildworld > Building an up-to-date make(1) > World build started on Thu Jul 11 02:57:14 UTC 2013 > Rebuilding the temporary build tree > stage 1.1: legacy release compatibility shims > stage 1.2: bootstrap tools > stage 2.1: cleaning up the object tree > stage 2.2: rebuilding the object tree > stage 2.3: build tools > stage 3: cross tools > stage 4.1: building includes > stage 4.2: building libraries > stage 4.3: make dependencies > stage 4.4: building everything > World build completed on Thu Jul 11 04:07:01 UTC 2013 > > TB --- 2013-07-11 04:07:01 - generating LINT kernel config > > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf > > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B LINT > > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf > > TB --- 2013-07-11 04:07:01 - /usr/sbin/config -m LINT > > TB --- 2013-07-11 04:07:01 - building LINT kernel > > TB --- 2013-07-11 04:07:01 - CROSS_BUILD_TESTING=YES > > TB --- 2013-07-11 04:07:01 - MAKEOBJDIRPREFIX=/obj > > TB --- 2013-07-11 04:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2013-07-11 04:07:01 - SRCCONF=/dev/null > > TB --- 2013-07-11 04:07:01 - TARGET=sparc64 > > TB --- 2013-07-11 04:07:01 - TARGET_ARCH=sparc64 > > TB --- 2013-07-11 04:07:01 - TZ=UTC > > TB --- 2013-07-11 04:07:01 - __MAKE_CONF=/dev/null > > TB --- 2013-07-11 04:07:01 - cd /src > > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B buildkernel KERNCONF=LINT > Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013 > stage 1: configuring the kernel > stage 2.1: cleaning up the object tree > stage 2.2: rebuilding the object tree > stage 2.3: build tools > stage 3.1: making dependencies > stage 3.2: building everything > > [...] > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > > -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. > > -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > > -include opt_global.h -fno-common -finline-limit=15000 --param > > inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin > > -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror > > /src/sys/net80211/ieee80211_mesh.c > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > > -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. > > -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > > -include opt_global.h -fno-common -finline-limit=15000 --param > > inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin > > -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror > > /src/sys/net80211/ieee80211_monitor.c > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > > -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. > > -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > > -include opt_global.h -fno-common -finline-limit=15000 --param > > inline-unit-growth
Re: My incremental buildworlds started failing
On Tue, Apr 16, 2013 at 10:06 AM, Tijl Coosemans wrote:
> On 2013-04-16 18:39, Dimitry Andric wrote:
> > On Apr 16, 2013, at 18:08, Bjoern A. Zeeb wrote:
> >> I have been seeing this on incremental buildworlds for a day or two now?
> >> ANyone can throw the cluebat at me?
>
> If that means building with NO_CLEAN=yes then the problem is r249484.
> It creates a symlink: ln -fs ../include ${DESTDIR}/usr/lib/include
> But if ${DESTDIR}/usr/lib/include already exists it creates
> ${DESTDIR}/usr/include/include -> ../include.
>
> I'm thinking of reverting that commit.
>
Has this been sorted out? Not being able to buildworld with NO_CLEAN is a
bit of a pain.
Navdeep
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DTrace gone quiet?
On 04/16/13 13:03, Ryan Stone wrote: > On Tue, Apr 16, 2013 at 3:57 PM, Navdeep Parhar <mailto:n...@freebsd.org>> wrote: > > I just upgraded my kernel and userspace to head (r249552) and I notice > that DTrace doesn't output anything until I hit ctrl-c. All previous > "hits" on the probe appear lost. For example: > > # dtrace -n 'fbt::ether_output:entry' > dtrace: description 'fbt::ether_output:entry' matched 1 probe > > (No output here. I waited a long time before the ctrl-c and I know the > system is actively transmitting and receiving Ethernet traffic). > > ^C > CPU IDFUNCTION:NAME > 9 29354 ether_output:entry > 8 29354 ether_output:entry > 8 29354 ether_output:entry > 8 29354 ether_output:entry > > > Can anyone confirm or contradict this on a recent HEAD (around r249552 > in my case)? > > Regards, > Navdeep > > > Hm, if you run with "-x bufpolicy=switch" does it work? It sounds as > through the ring buffer policy is being set by default for you. I'm not > sure how that could happen. No luck. trantor:~# dtrace -x bufpolicy=switch -n 'fbt::ether_output:entry' dtrace: description 'fbt::ether_output:entry' matched 1 probe (long fruitless wait here) ^C CPU IDFUNCTION:NAME 4 29354 ether_output:entry 3 29354 ether_output:entry 9 29354 ether_output:entry 3 29354 ether_output:entry ___ 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"
DTrace gone quiet?
I just upgraded my kernel and userspace to head (r249552) and I notice that DTrace doesn't output anything until I hit ctrl-c. All previous "hits" on the probe appear lost. For example: # dtrace -n 'fbt::ether_output:entry' dtrace: description 'fbt::ether_output:entry' matched 1 probe (No output here. I waited a long time before the ctrl-c and I know the system is actively transmitting and receiving Ethernet traffic). ^C CPU IDFUNCTION:NAME 9 29354 ether_output:entry 8 29354 ether_output:entry 8 29354 ether_output:entry 8 29354 ether_output:entry Can anyone confirm or contradict this on a recent HEAD (around r249552 in my case)? Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r247095 Boot Failure
On Thu, Feb 21, 2013 at 03:38:41PM +, matt wrote: > On Thu, Feb 21, 2013 at 3:34 PM, Navdeep Parhar wrote: > > > > > Take a look at the "-CURRENT userland regression" thread. You may be > > able to boot if you choose "safe mode" in the boot loader menu. > > > > Regards, > > Navdeep > > > > > What is safe mode as far as boot flags? This is the forth code that sets up safe mode: : safemode_enable ( -- ) s" set kern.smp.disabled=1" evaluate s" set hw.ata.ata_dma=0" evaluate s" set hw.ata.atapi_dma=0" evaluate s" set hw.ata.wc=0" evaluate s" set hw.eisa_slots=0" evaluate s" set kern.eventtimer.periodic=1" evaluate s" set kern.geom.part.check_integrity=0" evaluate ; loader.conf should be able to set up those variables too (temporarily, as a workaround). I wonder which one does the trick - smp.disabled or eventtimer_periodic, or ..? Regards, Navdeep > > boot -sv doesn't work on my system... > > Matt ___ 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: r247095 Boot Failure
On Thu, Feb 21, 2013 at 10:28:15AM -0500, Shawn Webb wrote: > I'm on r247095. My box is failing to boot on a Dell Precision T7500. I'm > running ZFS as root with a mirrored root pool. > > Here's a pic of the box failing: > https://lh5.googleusercontent.com/-Lq_jlX8of0o/USY4cqZ5BOI/GoI/Nd1LGPbFjHc/s1112/IMG_20130221_100723.jpg > > There isn't much useful information in the pic. No crash dump is generated. > Where do I go from here? Take a look at the "-CURRENT userland regression" thread. You may be able to boot if you choose "safe mode" in the boot loader menu. Regards, Navdeep > > I can boot into kernel.old and that works as a workaround for now. > > Thanks, > > Shawn > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT userland regression
On 02/20/13 14:47, Konstantin Belousov wrote: > On Wed, Feb 20, 2013 at 02:33:23PM -0800, Navdeep Parhar wrote: >> On 02/20/13 14:25, Konstantin Belousov wrote: >>> On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: >>>> On 02/20/13 14:14, Xin Li wrote: >>>>> Hi, >>>>> >>>>> It seems that fresh -HEAD would give an unusable kernel that >>>>> overwrites screen buffer in a way making it impossible to debug. >>>>> Using an old world source to do 'make buildworld buildkernel' results >>>>> in a (mostly: I have some strange USB issue right now and still >>>>> looking for the cause) usable kernel. >>>>> >>>>> For now my known good combination is world 246858 with kernel 247057. >>>>> I'm still trying to find out which revision have broke the stuff. >>>> >>>> I ran into this earlier today. Selecting "safe mode" in the boot loader >>>> menu seems to work around the problem on my system. Now I will not >>>> reboot until I see a fix for this in head :-) >>> >>> How much 'the earlier today' is ? >>> I.e., could you specify some revisions ? >>> >> >> I upgraded from a month old (approx.) head to r247054 and ran into this >> problem. I haven't tried bisecting as I need a running system right now. > > BTW, does the loader fails, or is it the kernel where the problems start > appearing ? > The problem occurs well after the kernel is up and running. The last messages that were readable were from ugen/uhub and ada0. The rest was garbled and the system froze solid something after that. I tried pinging it but it wasn't reachable so this wasn't a case where the console was trashed but system was running. This is amd64 built with clang. I have dual consoles - serial and VGA. FreeBSD trantor 10.0-CURRENT FreeBSD 10.0-CURRENT #26: Wed Feb 20 13:18:48 PST 2013 root@trantor:/usr/obj/usr/src/sys/TOEKTR amd64 Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT userland regression
On 02/20/13 14:25, Konstantin Belousov wrote: > On Wed, Feb 20, 2013 at 02:21:50PM -0800, Navdeep Parhar wrote: >> On 02/20/13 14:14, Xin Li wrote: >>> Hi, >>> >>> It seems that fresh -HEAD would give an unusable kernel that >>> overwrites screen buffer in a way making it impossible to debug. >>> Using an old world source to do 'make buildworld buildkernel' results >>> in a (mostly: I have some strange USB issue right now and still >>> looking for the cause) usable kernel. >>> >>> For now my known good combination is world 246858 with kernel 247057. >>> I'm still trying to find out which revision have broke the stuff. >> >> I ran into this earlier today. Selecting "safe mode" in the boot loader >> menu seems to work around the problem on my system. Now I will not >> reboot until I see a fix for this in head :-) > > How much 'the earlier today' is ? > I.e., could you specify some revisions ? > I upgraded from a month old (approx.) head to r247054 and ran into this problem. I haven't tried bisecting as I need a running system right now. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -CURRENT userland regression
On 02/20/13 14:14, Xin Li wrote: > Hi, > > It seems that fresh -HEAD would give an unusable kernel that > overwrites screen buffer in a way making it impossible to debug. > Using an old world source to do 'make buildworld buildkernel' results > in a (mostly: I have some strange USB issue right now and still > looking for the cause) usable kernel. > > For now my known good combination is world 246858 with kernel 247057. > I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting "safe mode" in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "Memory modified after free" - by whom?
On Mon, Dec 10, 2012 at 05:37:17PM -0800, Garrett Cooper wrote: > On Mon, Dec 10, 2012 at 3:21 PM, Adrian Chadd wrote: > > On 10 December 2012 15:18, wrote: > >> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote: > >>> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf > >>> after it's finalised/freed. > >>> > >>> I have a similar bug showing up on ath(4) RX. :( > >> > >> Compile with DEBUG_MEMGUARD in the kernel configuration, and then set > >> vm.memguard.desc to the name of the UMA zone used for the 9216 byte > >> allocations, mbuf_jumbo_9k. This should cause a panic when the memory > >> is touched after free. > > > > Right, but I think its a _hardware_ access after the buffer has been freed.. > > At least that will give me an idea of who to punt the bug over to > next (assuming it lists the driver) -- one of the network folks, jfv, > or np :). It seems to be a recent change that's causing this (it's > spewing out these warnings every couple seconds), but that might also > be related to me getting lagg working on CURRENT as my last known base > was 9-STABLE and a lot of networking changes haven't been MFCed :). If you suspect it's a DMA from the NIC after the 9K cluster has been freed, see if the "corrupt" portion looks anything like an Ethernet frame. If it does then the DMAC in the frame will tell you who to follow up with -- jfv@ or me :-) (btw, your log had "val=" so I think it's something else..) Regards, Navdeep > I could probably look through the code too after compiling it, but > it would take too long. > Thanks! > -Garrett > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Supermicro X8DT6 crashes in bootloader after r239066
On 11/14/12 03:17, Andriy Gapon wrote:
on 31/10/2012 07:31 Navdeep Parhar said the following:
I have one of these X8DT6 systems. It has grub2 as the primary boot
loader which then loads zfsloader. Many weeks back I updated the BIOS,
grub, and FreeBSD and ran into a similar problem -- zfsloader would
start, print a few messages, and then the system would reboot. I
tracked it down to the int 0x13 call (with eax=0x4800) in bd_int13probe.
It would walk past the end of the edd_params structure and corrupt the
return address on the stack. I worked around it by padding edd_params.
I was planning to debug it further to find out which of the 3 things
that were updated caused the problem but Other Things(tm) came up. See
if this works for you too:
diff -r d35d326e437a -r e5228169f3f1 sys/boot/i386/common/edd.h
--- a/sys/boot/i386/common/edd.hTue Oct 30 21:51:09 2012 -0700
+++ b/sys/boot/i386/common/edd.hTue Oct 30 21:51:20 2012 -0700
@@ -62,6 +62,7 @@ struct edd_params {
uint16_tsector_size;
uint16_tedd_params_seg;
uint16_tedd_params_off;
+ charpad[64];
};
Navdeep,
I've committed a different antidote for this BIOS bug as r243025.
Could you please that it works for you too?
Yes it works for me too, thanks Andriy!
Regards,
Navdeep
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Supermicro X8DT6 crashes in bootloader after r239066
On Tue, Oct 30, 2012 at 08:34:53PM -0400, Ryan Stone wrote:
> I have a X8DT6 that appears to crash in the bootloader from HEAD. I say
> "appears to" because it's difficult to really see what the problem is; the
> system reboots pretty much as soon as it enters the FreeBSD boot process.
> The problem affects PXE booting, booting from ZFS on GPT on a SATA drive
> and UFS on MBR on a USB stick.
>
> The problem only occurs if I have any SATA disks plugged in. If I remove
> all SATA disks I can successfully PXE boot or boot from a USB key. I've
> tried with a couple of different SATA disks, some with GPT and some with
> MBR, and the reboot happens in both cases.
>
> The last things that I see on the serial console before the reboot is:
>
> DHCP..-
>
> ^[[06;07H^[[06;00HDH
> CP..\
> ^[
> [06;07H^[[05;00HCLIENT MAC ADDR: 00 25 90 92 19 94 GUID: 84F7C23B 5F21
> 2533 625
> C 002590921994 ^[[06;00HCLIENT IP: 172.16.1.50 MASK: 255.255.255.0 DHCP
> IP: 1
> 72.16.1.1^[[07;00HGATEWAY IP:
> 172.16.1.1
> ^[[08;00HPXE Loader
> 1.00^[[2JM-^@^[[01;00H^[[0
> m^[[2m^[[0m^[[2;30;40m
> ^@^[[0m^[[2;37;40m
> ^[[02;00H^[[0m^[[2;30;40m
>
> So it really doesn't seem to get very far at all.
>
> I've bisected and confirmed that the problem was introduced in r239066. I
> tried reverting that commit locally and I can boot fine again. I took a
> quick look at that commit but it appears to be way over my head. I'm
> willing to test patches or gather more debugging information; this thing
> isn't going anywhere until I can get it booting. :)
I have one of these X8DT6 systems. It has grub2 as the primary boot
loader which then loads zfsloader. Many weeks back I updated the BIOS,
grub, and FreeBSD and ran into a similar problem -- zfsloader would
start, print a few messages, and then the system would reboot. I
tracked it down to the int 0x13 call (with eax=0x4800) in bd_int13probe.
It would walk past the end of the edd_params structure and corrupt the
return address on the stack. I worked around it by padding edd_params.
I was planning to debug it further to find out which of the 3 things
that were updated caused the problem but Other Things(tm) came up. See
if this works for you too:
diff -r d35d326e437a -r e5228169f3f1 sys/boot/i386/common/edd.h
--- a/sys/boot/i386/common/edd.hTue Oct 30 21:51:09 2012 -0700
+++ b/sys/boot/i386/common/edd.hTue Oct 30 21:51:20 2012 -0700
@@ -62,6 +62,7 @@ struct edd_params {
uint16_tsector_size;
uint16_tedd_params_seg;
uint16_tedd_params_off;
+ charpad[64];
};
Regards,
Navdeep
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NICs not in GENERIC
On Tue, Feb 21, 2012 at 05:44:01PM -0700, Scott Long wrote: > > On Feb 21, 2012, at 10:51 AM, Navdeep Parhar wrote: > > > On Tue, Feb 21, 2012 at 03:56:56PM +0100, Alexander Leidinger wrote: > >> Hi, > >> > >> is there a specific reason that the following NICs are not (or shall > >> not be) in GENERIC (at least on i386)? > > > > No specific reason for these two: > > > >> - if_cxgb > >> - if_cxgbe > > > > But I do prefer to load them as modules (and as late as possible -- > > after sysctl.conf has been processed and any nmbclusters, nmbjumboXX > > settings have taken affect). > > > > Other than root over NFS, is there any reason to have NIC drivers in > > GENERIC? > > > > GENERIC is the kernel profile that's used during installation, and the > installer (at one point in time) supported installing over NFS and FTP. If the installer itself can come up without the NIC driver it should be able to load any NIC driver KLD it wants and then reach the "install media" (NFS, FTP, etc.) over the network. Or is it that the installer's root fs didn't have any KLDs back then? Navdeep > GENERIC was also a good smoke test to see if FreeBSD would run on a newly > purchased machine, since it included most drivers. > > Scott > > ___ 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: NICs not in GENERIC
On Tue, Feb 21, 2012 at 03:56:56PM +0100, Alexander Leidinger wrote: > Hi, > > is there a specific reason that the following NICs are not (or shall > not be) in GENERIC (at least on i386)? No specific reason for these two: > - if_cxgb > - if_cxgbe But I do prefer to load them as modules (and as late as possible -- after sysctl.conf has been processed and any nmbclusters, nmbjumboXX settings have taken affect). Other than root over NFS, is there any reason to have NIC drivers in GENERIC? Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld race?
On Tue, Nov 22, 2011 at 10:35 AM, Andreas Tobler wrote: > Anyone seen this too? > Yes, I've been running into this error too. Navdeep > make: don't know how to make > /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop > *** Error code 2 > > Happens on amd64 and powerpc64 while doing a make -j4 buildworld. > Continuing with -DNO_CLEAN -j1 completes the build. > > Thanks, > Andreas > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SVN -> CVS exporter issue?
On Thu, Aug 11, 2011 at 07:26:36PM -0400, Michael Butler wrote: > I'm not seeing any of today's SVN src updates flow through to CVS/CSUP. > Is it broken? Could it be because of r224768? I vaguely recall that "svn mv" bothers whatever it is that converts from svn -> cvs. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
duplicate output when dumping from ddb
"dump" or "call doadump" from within ddb display duplicate output. This is with a serial console. I have console="comconsole,vidconsole" in /boot/loader.conf and "-D -S115200" in /boot.config. db> dump Dumping 1883 out of 12255 MB:Dumping 1883 out of 12255 MB:..1%..1%..11%..11%..21%..21%..31%..31%..41%..41%..51%..51%..61%..61%..71%..71%..81%..81%..91%..91% Dump complete Dump complete db> Something seems to have changed in the last couple of months or so. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: awk(1) segfaults when building kernel modules
On Wed, Aug 10, 2011 at 11:12 AM, Test Rat wrote: > `make -s buildkernel' seems to contain lots of segfaults after recent > update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk. ... > > Anyone else? I see this too. ___ 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: KGDB stack traces in the kernel.
On Tue, Apr 5, 2011 at 1:33 PM, Julian Elischer wrote: > On 4/4/11 6:04 PM, Justin Hibbits wrote: >> >> On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: >>> >>> is there anyone here with enough gdb/kgdb source experience to know what >>> we would need to put on the stack at fork_exit() to make it stop when it >>> gets there? >>> >>> not only is it annoying but it slows down debugging because kgdb and the >>> ddd >>> front end ask for stacks a LOT. sometimes it actually just hangs as the >>> stack >>> goes into a loop and never ends. >>> >>> I had a quick look but didn't spot how gdb decides it has reached the end >>> of a stack. >>> >>> Julian >> >> From my experience, it checks for a NULL stack chain pointer. Once that >> reaches NULL, it's the end of the stack. >> >> - Justin >> > I'll try adding NULL when we build the intial stack up. > :-) What does ddb do? It always seems to get this stuff correct. Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't compile today's kernel: sys/cam/cam.c + CTF
On Fri, Jul 23, 2010 at 3:40 PM, Doug Barton wrote: > On Fri, 23 Jul 2010, Navdeep Parhar wrote: > >> On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton wrote: >>> >>> I'm getting this with r210435. World built fine: >>> >>> cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall >>> -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>> -Wmissing-prototypes >>> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign >>> -fformat-extensions -nostdinc -I. -I/usr/local/src/sys >>> -I/usr/local/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS >>> -include opt_global.h -fno-common -finline-limit=8000 --param >>> inline-unit-growth=100 --param large-function-growth=1000 >>> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow >>> -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror >>> /usr/local/src/sys/i386/i386/locore.s >>> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs >>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline >>> -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. >>> -I/usr/local/src/sys -I/usr/local/src/sys/contrib/altq -D_KERNEL >>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >>> -finline-limit=8000 --param inline-unit-growth=100 --param >>> large-function-growth=1000 -mno-align-long-strings >>> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >>> -mno-sse3 -ffreestanding -fstack-protector -Werror >>> /usr/local/src/sys/cam/cam.c >>> *** Signal 11 >>> >>> Removing makeoptions WITH_CTF=yes does the trick. >> >> I ran into this earlier today. ctfconvert would dump core during >> buildkernel. >> Please try r210438 > > I updated to that revision, tried just rebuilding ctfconvert, didn't work. > Then I tried installing the new ctfconvert, still doesn't work. Do I need to > go farther up the tree? Hmm. I think a "make toolchain" in /usr/src before you build your kernel should fix it. You probably have an old ctfconvert sitting around. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't compile today's kernel: sys/cam/cam.c + CTF
On Fri, Jul 23, 2010 at 3:22 PM, Doug Barton wrote: > I'm getting this with r210435. World built fine: > > cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -nostdinc -I. -I/usr/local/src/sys > -I/usr/local/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/local/src/sys/i386/i386/locore.s > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. > -I/usr/local/src/sys -I/usr/local/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/local/src/sys/cam/cam.c > *** Signal 11 > > Removing makeoptions WITH_CTF=yes does the trick. I ran into this earlier today. ctfconvert would dump core during buildkernel. Please try r210438 Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Why is intr taking up so much cpu?
On Mon, Jul 19, 2010 at 07:33:01PM -0700, Doug Barton wrote: > On Mon, 19 Jul 2010, Chris Ruiz wrote: > > >On Mon, Jul 19, 2010 at 8:03 PM, Doug Barton wrote: > >>I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and > >>rebooted. I decided to try your script before things went sideways so I'd > >>have an idea of what to expect, and it didn't work: > >> > >>dtrace: failed to initialize dtrace: DTrace device not available on system > >> > >>Is there something else I need to do to enable it? > > > >You need to build the kernel with CTF. Try adding "makeoptions > >WITH_CTF=yes" to your config and rebuilding your kernel. There's a > >blurb in src/UPDATING about other ways to accomplish the same thing. > > Thanks for the suggestion, but no improvement. Doing: > strings /boot/kernel/kernel | grep -i dtrace > > Shows lots of dtrace-related entries, unlike previous kernels built > without the KDTRACE_HOOKS option, but same error with Dan's script. Try a "kldload dtraceall" before running the script. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
On Thu, Apr 22, 2010 at 09:44:47AM +0200, Alexander Leidinger wrote: > Quoting Navdeep Parhar (from Wed, 21 Apr 2010 > 18:23:33 -0700): > > >Your patch works for me, thanks. There is just one more problem with the CTF > > I found a case where it does not work (not kernel related), I have > another one which works better. > > >generation that needs to be fixed: > > > >http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html > > > >While you're here can you take a look at the patch in that email too? > > Looks good in concept, but the CTFMERGE line needs the same > treatment like all the other ones in the .mk files. I want to commit > a suitable change today. Does "same treatment" mean it should run silently too? My personal opinion is that all ctfconvert and ctfmerge commands should show up in the output of make iff they run. I believe that used to be the case before r206082. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
On Fri, Apr 16, 2010 at 03:51:40PM +0200, Alexander Leidinger wrote:
> Quoting Navdeep Parhar (from Wed, 14 Apr 2010
> 11:35:40 -0700):
>
> >Have you or anyone else ever used buildkernel successfully with
> >"makeoptions WITH_CTF=yes" in the conf file? Something as simple as
> >this does not work for me:
>
> Copy&paste patch, tabs probbly mangled:
> ---snip---
> Index: Makefile.inc1
> ===
> --- Makefile.inc1 (revision 206700)
> +++ Makefile.inc1 (working copy)
> @@ -314,7 +314,7 @@
> .endif
>
> # kernel stage
> -KMAKEENV= ${WMAKEENV}
> +KMAKEENV= ${WMAKEENV:NNO_CTF=1}
> KMAKE= ${KMAKEENV} ${MAKE} KERNEL=${INSTKERNNAME}
>
> #
> @@ -780,7 +780,7 @@
> @echo "--"
> cd ${KRNLOBJDIR}/${_kernel}; \
> MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \
> - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \
> + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS \
> -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile
> # XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case.
> .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) &&
> exists(${KERNSRCDIR}/modules)
> ---snip---
>
> This lets the buildkernel generate ctf info in the object files (the
> build is not finished yet, so I still have to verify that the final
> kernel contains them too, but I do not see a reason ATM why this
> should not be the case).
Your patch works for me, thanks. There is just one more problem with the CTF
generation that needs to be fixed:
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html
While you're here can you take a look at the patch in that email too?
Regards,
Navdeep
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
On Wed, Apr 14, 2010 at 01:23:42PM +0200, Alexander Leidinger wrote: > Quoting Navdeep Parhar (from Wed, 14 Apr 2010 > 02:31:30 -0700): > > >On Wed, Apr 14, 2010 at 1:58 AM, Alexander Leidinger > > wrote: > >>Quoting Navdeep Parhar (from Wed, 14 Apr 2010 01:33:29 > >>-0700): > >> > >>>I read the UPDATING entry that accompanied r206082 and added WITH_CTF=yes > >>>to > >>>my kernel config, hoping to get CTF information in the kernel and all > >>>modules. No luck. > >>>It appears that NO_CTF remains set to 1 inspite of the undef NO_CTF in > >>>various .mk files > >>>and ctfconvert never runs. > >> > >>This is the output I get in my kernel build directory: > >>---snip--- > >># make -V NO_CTF -V WITH_CTF > >> > >>yes > > > >Can you also try a "makeoptions WITH_CTF=yes" in your KERNCONF > > The above one is with WITH_CTF in my kernel config, but this was > generated manually with cd /sys/i386/conf; config CONF; cd > ../compile/CONF; make -V... > > >and see if the results are as expected? How was r206082 tested? I'm > >trying to figure out the differences, if any, between your build setup and > >mine. > > I made a buildworld with and without WITH_CTF in src.conf to confirm > that it works (no installkernel, as the world is known to be not > useable with CTF), and I did a lot of tests by hand as above > (config;make). Have you or anyone else ever used buildkernel successfully with "makeoptions WITH_CTF=yes" in the conf file? Something as simple as this does not work for me: - pristine sources in /usr/src, empty /usr/obj, no /etc/make.conf, no /etc/src.conf - add "makeoptions WITH_CTF=yes" in sys/amd64/conf/GENERIC - make buildkernel in /usr/src The result is a kernel without CTF information. The log is at http://www.freebsd.org/~np/WITH_CTF.log Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
On Wed, Apr 14, 2010 at 1:58 AM, Alexander Leidinger
wrote:
> Quoting Navdeep Parhar (from Wed, 14 Apr 2010 01:33:29
> -0700):
>
>> I read the UPDATING entry that accompanied r206082 and added WITH_CTF=yes
>> to
>> my kernel config, hoping to get CTF information in the kernel and all
>> modules. No luck.
>> It appears that NO_CTF remains set to 1 inspite of the undef NO_CTF in
>> various .mk files
>> and ctfconvert never runs.
>
> This is the output I get in my kernel build directory:
> ---snip---
> # make -V NO_CTF -V WITH_CTF
>
> yes
Can you also try a "makeoptions WITH_CTF=yes" in your KERNCONF
and see if the results are as expected? How was r206082 tested? I'm
trying to figure out the differences, if any, between your build setup and
mine.
> ---snip---
>
>> I built the kernel with a "make -j16 buildkernel" in /usr/src.
>
> How do you determine if ctfconvert is run or not?
I got rid of the @ in front of all the CTF commands in all the .mk files. I
could see that NO_CTF was 1 and so the ctfconvert after || wouldn't
run.
[ -z "${CTFCONVERT}" -o -n "${NO_CTF}" ] || ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
[ -z "ctfconvert" -o -n "1" ] ||
Do you see anything different if you remove all the @'s?
> If you expect to see
> ctfconvert lines in the build output: this will not be the case, no matter
> if you enable it or not. With the current way of handling it, I'm not aware
> of a way how to print the command when ctfconvert is really executed (we can
> maybe add an echo which prints out something, but the question is if this is
> worth the effort).
>
> You can run objdump -f and have a look if the .SUNW_ctf section
> is there to determine if CTF stuff was inserted or not.
I tried this:
# ctfdump /usr/obj/usr/src/sys/GENERIC/kernel
/usr/obj/usr/src/sys/GENERIC/kernel does not contain .SUNW_ctf data
Regards,
Navdeep
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
> http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
> The Force is what holds everything together.
> It has its dark side, and it has its light side.
> It's sort of like cosmic duct tape.
>
>
___
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"
Does "makeoptions WITH_CTF=yes" actually work?
I read the UPDATING entry that accompanied r206082 and added WITH_CTF=yes to my kernel config, hoping to get CTF information in the kernel and all modules. No luck. It appears that NO_CTF remains set to 1 inspite of the undef NO_CTF in various .mk files and ctfconvert never runs. Can anyone confirm whether r206082 works as advertised or not? This is the diff between my config and amd64/conf/GENERIC: 24a25 > makeoptions WITH_CTF=yes 66,67c67,68 < #options KDTRACE_FRAME # Ensure frames are compiled in < #options KDTRACE_HOOKS # Kernel DTrace hooks --- > options KDTRACE_FRAME # Ensure frames are compiled in > options KDTRACE_HOOKS # Kernel DTrace hooks 72a74 > options DDB_CTF This is /etc/make.conf on my system: CPUTYPE?=core2 DEBUG_FLAGS=-g -fno-inline-functions -fno-inline-functions-called-once I built the kernel with a "make -j16 buildkernel" in /usr/src. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
