Re: No more update on stable/12

[Peter Blok]

I just removed the previous workspace and did git clone -b stable/12 --depth 1 
https://git.freebsd.org/src.git src 

> On 30 Dec 2020, at 21:18, Tj  wrote:
> 
> Wait, what exactly did you do btw? I tried just switching the url and now
> i'm  getting "your branch and Origin/stable/12 have diverged, and have
> 261519 and 243116 different commits each, respectively" is the github
> stable/12 not the same as the freebsd.org one?
> 
> On Wed, 30 Dec 2020 at 08:30, Peter Blok  wrote:
> 
>> I was using github instead of the git repository below.
>> 
>> Thx. All set now
>> 
>> Peter
>> 
>>> On 30 Dec 2020, at 10:32, Yasuhiro Kimura  wrote:
>>> 
>>> From: Peter Blok 
>>> Subject: No more update on stable/12
>>> Date: Wed, 30 Dec 2020 10:24:27 +0100
>>> 
>>>> I switched to git, but I noticed there were no MFC or any other updates
>> over the last couple of days after the migration. git fetch doesn’t show
>> any change.
>>>> 
>>>> Is this correct and just the learning process of git or is something
>> wrong with my git clone?
>>> 
>>> Which repository do you use?. Currently new canonical src repository
>>> (https://git.freebsd.org/src.git) is updated but not mirrored to
>>> GitHub yet.
>>> 
>>> ---
>>> Yasuhiro Kimura
>>> ___
>>> freebsd-stable@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org
>> "
>> 
>> 
> 
> -- 
> --
> -Tj Hariharan
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



smime.p7s
Description: S/MIME cryptographic signature

Re: No more update on stable/12

[Peter Blok]

I was using github instead of the git repository below.

Thx. All set now

Peter

> On 30 Dec 2020, at 10:32, Yasuhiro Kimura  wrote:
> 
> From: Peter Blok 
> Subject: No more update on stable/12
> Date: Wed, 30 Dec 2020 10:24:27 +0100
> 
>> I switched to git, but I noticed there were no MFC or any other updates over 
>> the last couple of days after the migration. git fetch doesn’t show any 
>> change.
>> 
>> Is this correct and just the learning process of git or is something wrong 
>> with my git clone?
> 
> Which repository do you use?. Currently new canonical src repository
> (https://git.freebsd.org/src.git) is updated but not mirrored to
> GitHub yet.
> 
> ---
> Yasuhiro Kimura
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



smime.p7s
Description: S/MIME cryptographic signature

No more update on stable/12

[Peter Blok]

Hi,

I switched to git, but I noticed there were no MFC or any other updates over 
the last couple of days after the migration. git fetch doesn’t show any change.

Is this correct and just the learning process of git or is something wrong with 
my git clone?

Peter




smime.p7s
Description: S/MIME cryptographic signature

Re: Commit 367705+367706 causes a pabic

[Peter Blok]

Kristof,

It’s from the 2nd situation. It is so weird. Last time there was ipsec code in 
the backtrace, which wasn’t used on the bridge+members.

This is from my own kernel config, but during testing with the GENERIC kernel I 
had similar backtraces at reboot.

I can’t do a lot right now, but I’m planning to:

- build kernel with -O0
- do the deletem of the epair manually

I’ll get back to you if I find something.

Peter

> On 23 Nov 2020, at 12:15, Kristof Provost  wrote:
> 
> Peter,
> 
> Is that backtrace from the first or the second situation you describe? What 
> kernel config are you using with that backtrace?
> 
> This backtrace does not appear to involve the bridge. Given that part of the 
> panic message is cut off it’s very hard to conclude anything at all from it.
> 
> Best regards,
> Kristof
> 
> On 23 Nov 2020, at 11:52, Peter Blok wrote:
> 
>> Kristof,
>> 
>> With commit 367705+367706 and if_bridge statically linked. It crashes while 
>> adding an epair of a jail.
>> 
>> With commit 367705+367706 and if_bridge dynamically loaded there is a crash 
>> at reboot
>> 
>> #0 0x8069ddc5 at kdb_backtrace+0x65
>> #1 0x80652c8b at vpanic+0x17b
>> #2 0x80652b03 at panic+0x43
>> #3 0x809c8951 at trap_fatal+0x391
>> #4 0x809c89af at trap_pfault+0x4f
>> #5 0x809c7ff6 at trap+0x286
>> #6 0x809a1ec8 at calltrap+0x8
>> #7 0x8079f7ed at ip_input+0x63d
>> #8 0x8077a07a at netisr_dispatch_src+0xca
>> #9 0x8075a6f8 at ether_demux+0x138
>> #10 0x8075b9bb at ether_nh_input+0x33b
>> #11 0x8077a07a at netisr_dispatch_src+0xca
>> #12 0x8075ab1b at ether_input+0x4b
>> #13 0x8077a80b at swi_net+0x12b
>> #14 0xffff8061e10c at ithread_loop+0x23c
>> #15 0x8061afbe at fork_exit+0x7e
>> #16 0x809a2efe at fork_trampoline+0xe
>> 
>> Peter
>> 
>>> On 21 Nov 2020, at 17:22, Peter Blok  wrote:
>>> 
>>> Kristof,
>>> 
>>> With a GENERIC kernel it does NOT happen. I do have a different iflib 
>>> related panic at reboot, but I’ll report that separately.
>>> 
>>> I brought the two config files closer together and found out that if I 
>>> remove if_bridge from the config file and have it loaded dynamically when 
>>> the bridge is created, the problem no longer happens and everything works 
>>> ok.
>>> 
>>> Peter
>>> 
>>>> On 20 Nov 2020, at 15:53, Kristof Provost  wrote:
>>>> 
>>>> I still can’t reproduce that panic.
>>>> 
>>>> Does it happen immediately after you start a vnet jail?
>>>> 
>>>> Does it also happen with a GENERIC kernel?
>>>> 
>>>> Regards,
>>>> Kristof
>>>> 
>>>> On 20 Nov 2020, at 14:53, Peter Blok wrote:
>>>> 
>>>>> The panic with ipsec code in the backtrace was already very strange. I 
>>>>> was using IPsec, but only on one interface totally separate from the 
>>>>> members of the bridge as well as the bridge itself. The jails were not 
>>>>> doing any ipsec as well. Note that panic was a while ago and it was after 
>>>>> the 1st bridge epochification was done on stable-12 which was later 
>>>>> backed out
>>>>> 
>>>>> Today the system is no longer using ipsec, but it is still compiled in. I 
>>>>> can remove it if need be for a test
>>>>> 
>>>>> 
>>>>> src.conf
>>>>> WITHOUT_KERBEROS=yes
>>>>> WITHOUT_GSSAPI=yes
>>>>> WITHOUT_SENDMAIL=true
>>>>> WITHOUT_MAILWRAPPER=true
>>>>> WITHOUT_DMAGENT=true
>>>>> WITHOUT_GAMES=true
>>>>> WITHOUT_IPFILTER=true
>>>>> WITHOUT_UNBOUND=true
>>>>> WITHOUT_PROFILE=true
>>>>> WITHOUT_ATM=true
>>>>> WITHOUT_BSNMP=true
>>>>> #WITHOUT_CROSS_COMPILER=true
>>>>> WITHOUT_DEBUG_FILES=true
>>>>> WITHOUT_DICT=true
>>>>> WITHOUT_FLOPPY=true
>>>>> WITHOUT_HTML=true
>>>>> WITHOUT_HYPERV=true
>>>>> WITHOUT_NDIS=true
>>>>> WITHOUT_NIS=true
>>>>> WITHOUT_PPP=true
>>>>> WITHOUT_TALK=true
>>>>> WITHOUT_TESTS=true
>>>>> WITHOUT_WIRELESS=true
>>>>> #WITHOUT_LIB32=true
>>>>> WITHOUT_LPR=true
>>>>> 
>>>>>

Re: Commit 367705+367706 causes a pabic

[Peter Blok]

Kristof,

With commit 367705+367706 and if_bridge statically linked. It crashes while 
adding an epair of a jail.

With commit 367705+367706 and if_bridge dynamically loaded there is a crash at 
reboot

#0 0x8069ddc5 at kdb_backtrace+0x65
#1 0x80652c8b at vpanic+0x17b
#2 0x80652b03 at panic+0x43
#3 0x809c8951 at trap_fatal+0x391
#4 0x809c89af at trap_pfault+0x4f
#5 0x809c7ff6 at trap+0x286
#6 0x809a1ec8 at calltrap+0x8
#7 0x8079f7ed at ip_input+0x63d
#8 0x8077a07a at netisr_dispatch_src+0xca
#9 0x8075a6f8 at ether_demux+0x138
#10 0x8075b9bb at ether_nh_input+0x33b
#11 0x8077a07a at netisr_dispatch_src+0xca
#12 0x8075ab1b at ether_input+0x4b
#13 0x8077a80b at swi_net+0x12b
#14 0x8061e10c at ithread_loop+0x23c
#15 0x8061afbe at fork_exit+0x7e
#16 0x809a2efe at fork_trampoline+0xe

Peter

> On 21 Nov 2020, at 17:22, Peter Blok  wrote:
> 
> Kristof,
> 
> With a GENERIC kernel it does NOT happen. I do have a different iflib related 
> panic at reboot, but I’ll report that separately.
> 
> I brought the two config files closer together and found out that if I remove 
> if_bridge from the config file and have it loaded dynamically when the bridge 
> is created, the problem no longer happens and everything works ok.
> 
> Peter
> 
>> On 20 Nov 2020, at 15:53, Kristof Provost  wrote:
>> 
>> I still can’t reproduce that panic.
>> 
>> Does it happen immediately after you start a vnet jail?
>> 
>> Does it also happen with a GENERIC kernel?
>> 
>> Regards,
>> Kristof
>> 
>> On 20 Nov 2020, at 14:53, Peter Blok wrote:
>> 
>>> The panic with ipsec code in the backtrace was already very strange. I was 
>>> using IPsec, but only on one interface totally separate from the members of 
>>> the bridge as well as the bridge itself. The jails were not doing any ipsec 
>>> as well. Note that panic was a while ago and it was after the 1st bridge 
>>> epochification was done on stable-12 which was later backed out
>>> 
>>> Today the system is no longer using ipsec, but it is still compiled in. I 
>>> can remove it if need be for a test
>>> 
>>> 
>>> src.conf
>>> WITHOUT_KERBEROS=yes
>>> WITHOUT_GSSAPI=yes
>>> WITHOUT_SENDMAIL=true
>>> WITHOUT_MAILWRAPPER=true
>>> WITHOUT_DMAGENT=true
>>> WITHOUT_GAMES=true
>>> WITHOUT_IPFILTER=true
>>> WITHOUT_UNBOUND=true
>>> WITHOUT_PROFILE=true
>>> WITHOUT_ATM=true
>>> WITHOUT_BSNMP=true
>>> #WITHOUT_CROSS_COMPILER=true
>>> WITHOUT_DEBUG_FILES=true
>>> WITHOUT_DICT=true
>>> WITHOUT_FLOPPY=true
>>> WITHOUT_HTML=true
>>> WITHOUT_HYPERV=true
>>> WITHOUT_NDIS=true
>>> WITHOUT_NIS=true
>>> WITHOUT_PPP=true
>>> WITHOUT_TALK=true
>>> WITHOUT_TESTS=true
>>> WITHOUT_WIRELESS=true
>>> #WITHOUT_LIB32=true
>>> WITHOUT_LPR=true
>>> 
>>> make.conf
>>> KERNCONF=BHYVE
>>> MODULES_OVERRIDE=opensolaris dtrace zfs vmm nmdm if_bridge bridgestp 
>>> if_vxlan pflog libmchain libiconv smbfs linux linux64 linux_common linuxkpi 
>>> linprocfs linsysfs ext2fs
>>> DEFAULT_VERSIONS+=perl5=5.30 mysql=5.7 python=3.8 python3=3.8
>>> OPTIONS_UNSET=DOCS NLS MANPAGES
>>> 
>>> BHYVE
>>> cpu HAMMER
>>> ident   BHYVE
>>> 
>>> makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols
>>> makeoptions WITH_CTF=1  # Run ctfconvert(1) for DTrace support
>>> 
>>> options CAMDEBUG
>>> 
>>> options SCHED_ULE   # ULE scheduler
>>> options PREEMPTION  # Enable kernel thread preemption
>>> options INET# InterNETworking
>>> options INET6   # IPv6 communications protocols
>>> options IPSEC
>>> options TCP_OFFLOAD # TCP offload
>>> options TCP_RFC7413 # TCP FASTOPEN
>>> options SCTP# Stream Control Transmission Protocol
>>> options FFS # Berkeley Fast Filesystem
>>> options SOFTUPDATES # Enable FFS soft updates support
>>> options UFS_ACL # Support for access control lists
>>> options UFS_DIRHASH # Improve performance on big directories
>>> options UFS_GJOURNAL# Enable gjournal-based UFS journaling
>

Re: Commit 367705+367706 causes a pabic

[Peter Blok]

Kristof,

With a GENERIC kernel it does NOT happen. I do have a different iflib related 
panic at reboot, but I’ll report that separately.

I brought the two config files closer together and found out that if I remove 
if_bridge from the config file and have it loaded dynamically when the bridge 
is created, the problem no longer happens and everything works ok.

Peter

> On 20 Nov 2020, at 15:53, Kristof Provost  wrote:
> 
> I still can’t reproduce that panic.
> 
> Does it happen immediately after you start a vnet jail?
> 
> Does it also happen with a GENERIC kernel?
> 
> Regards,
> Kristof
> 
> On 20 Nov 2020, at 14:53, Peter Blok wrote:
> 
>> The panic with ipsec code in the backtrace was already very strange. I was 
>> using IPsec, but only on one interface totally separate from the members of 
>> the bridge as well as the bridge itself. The jails were not doing any ipsec 
>> as well. Note that panic was a while ago and it was after the 1st bridge 
>> epochification was done on stable-12 which was later backed out
>> 
>> Today the system is no longer using ipsec, but it is still compiled in. I 
>> can remove it if need be for a test
>> 
>> 
>> src.conf
>> WITHOUT_KERBEROS=yes
>> WITHOUT_GSSAPI=yes
>> WITHOUT_SENDMAIL=true
>> WITHOUT_MAILWRAPPER=true
>> WITHOUT_DMAGENT=true
>> WITHOUT_GAMES=true
>> WITHOUT_IPFILTER=true
>> WITHOUT_UNBOUND=true
>> WITHOUT_PROFILE=true
>> WITHOUT_ATM=true
>> WITHOUT_BSNMP=true
>> #WITHOUT_CROSS_COMPILER=true
>> WITHOUT_DEBUG_FILES=true
>> WITHOUT_DICT=true
>> WITHOUT_FLOPPY=true
>> WITHOUT_HTML=true
>> WITHOUT_HYPERV=true
>> WITHOUT_NDIS=true
>> WITHOUT_NIS=true
>> WITHOUT_PPP=true
>> WITHOUT_TALK=true
>> WITHOUT_TESTS=true
>> WITHOUT_WIRELESS=true
>> #WITHOUT_LIB32=true
>> WITHOUT_LPR=true
>> 
>> make.conf
>> KERNCONF=BHYVE
>> MODULES_OVERRIDE=opensolaris dtrace zfs vmm nmdm if_bridge bridgestp 
>> if_vxlan pflog libmchain libiconv smbfs linux linux64 linux_common linuxkpi 
>> linprocfs linsysfs ext2fs
>> DEFAULT_VERSIONS+=perl5=5.30 mysql=5.7 python=3.8 python3=3.8
>> OPTIONS_UNSET=DOCS NLS MANPAGES
>> 
>> BHYVE
>> cpu  HAMMER
>> identBHYVE
>> 
>> makeoptions  DEBUG=-g# Build kernel with gdb(1) debug symbols
>> makeoptions  WITH_CTF=1  # Run ctfconvert(1) for DTrace support
>> 
>> options  CAMDEBUG
>> 
>> options  SCHED_ULE   # ULE scheduler
>> options  PREEMPTION  # Enable kernel thread preemption
>> options  INET# InterNETworking
>> options  INET6   # IPv6 communications protocols
>> options  IPSEC
>> options  TCP_OFFLOAD # TCP offload
>> options  TCP_RFC7413 # TCP FASTOPEN
>> options  SCTP# Stream Control Transmission Protocol
>> options  FFS # Berkeley Fast Filesystem
>> options  SOFTUPDATES # Enable FFS soft updates support
>> options  UFS_ACL # Support for access control lists
>> options  UFS_DIRHASH # Improve performance on big directories
>> options  UFS_GJOURNAL# Enable gjournal-based UFS journaling
>> options  QUOTA   # Enable disk quotas for UFS
>> options  SUIDDIR
>> options  NFSCL   # Network Filesystem Client
>> options  NFSD# Network Filesystem Server
>> options  NFSLOCKD# Network Lock Manager
>> options  MSDOSFS # MSDOS Filesystem
>> options  CD9660  # ISO 9660 Filesystem
>> options  FUSEFS
>> options  NULLFS  # NULL filesystem
>> options  UNIONFS
>> options  FDESCFS # File descriptor filesystem
>> options  PROCFS  # Process filesystem (requires PSEUDOFS)
>> options  PSEUDOFS# Pseudo-filesystem framework
>> options  GEOM_PART_GPT   # GUID Partition Tables.
>> options  GEOM_RAID   # Soft RAID functionality.
>> options  GEOM_LABEL  # Provides labelization
>> options  GEOM_ELI# Disk encryption.
>> options  COMPAT_FREEBSD32# Compatible with i386 binaries
>> options  COMPAT_FREEBSD4 # Compatible with FreeBSD4
>> options  COMPAT_FREEBSD5 # Compatible with Fre

Re: Commit 367705+367706 causes a pabic

[Peter Blok]

 are compiled in
options KDTRACE_HOOKS   # Kernel DTrace hooks
options DDB_CTF # Kernel ELF linker loads CTF data
options INCLUDE_CONFIG_FILE # Include this file in kernel

# Debugging support.  Always need this:
options KDB # Enable kernel debugger support.
options KDB_TRACE   # Print a stack trace for a panic.
options KDB_UNATTENDED

# Make an SMP-capable kernel by default
options SMP # Symmetric MultiProcessor Kernel
options EARLY_AP_STARTUP

# CPU frequency control
device  cpufreq
device  cpuctl
device  coretemp

# Bus support.
device  acpi
options ACPI_DMAR
device  pci
options PCI_IOV # PCI SR-IOV support

device  iicbus
device  iicbb

device  iic
device  ic
device  iicsmb

device  ichsmb
device  smbus
device  smb

#device jedec_dimm

# ATA controllers
device  ahci# AHCI-compatible SATA controllers
device  mvs # Marvell 
88SX50XX/88SX60XX/88SX70XX/SoC SATA

# SCSI Controllers
device  mps # LSI-Logic MPT-Fusion 2

# ATA/SCSI peripherals
device  scbus   # SCSI bus (required for ATA/SCSI)
device  da  # Direct Access (disks)
device  cd  # CD
device  pass# Passthrough device (direct ATA/SCSI 
access)
device  ses # Enclosure Services (SES and SAF-TE)
device  sg

device  cfiscsi
device  ctl # CAM Target Layer
device  iscsi

# atkbdc0 controls both the keyboard and the PS/2 mouse
device  atkbdc  # AT keyboard controller
device  atkbd   # AT keyboard
device  psm # PS/2 mouse

device  kbdmux  # keyboard multiplexer

# vt is the new video console driver
device  vt
device  vt_vga
device  vt_efifb

# Serial (COM) ports
device  uart# Generic UART driver

# PCI/PCI-X/PCIe Ethernet NICs that use iflib infrastructure
device  iflib
device  em  # Intel PRO/1000 Gigabit Ethernet Family
device  ix  # Intel PRO/10GbE PCIE PF Ethernet

# Network stack virtualization.
options VIMAGE

# Pseudo devices.
device  crypto
device  cryptodev
device  loop# Network loopback
device  random  # Entropy device
device  padlock_rng # VIA Padlock RNG
device  rdrand_rng  # Intel Bull Mountain RNG
device  ipmi
device  smbios
device  vpd
device  aesni   # AES-NI OpenCrypto module
device  ether   # Ethernet support
device  lagg
device  vlan# 802.1Q VLAN support
device  tuntap  # Packet tunnel.
device  md  # Memory "disks"
device  gif # IPv6 and IPv4 tunneling
device  firmware# firmware assist module

device  pf
#device pflog
#device pfsync

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device  bpf # Berkeley packet filter

# The `epair' device implements a virtual back-to-back connected Ethernet
# like interface pair.
device  epair

# USB support
options USB_DEBUG   # enable debug msgs
device  uhci# UHCI PCI->USB interface
device  ohci# OHCI PCI->USB interface
device  ehci# EHCI PCI->USB interface (USB 2.0)
device  xhci# XHCI PCI->USB interface (USB 3.0)
device  usb # USB Bus (required)
device  uhid
device  ukbd# Keyboard
device  umass   # Disks/Mass storage - Requires scbus 
and da
device  ums

device  filemon

device  if_bridge

> On 20 Nov 2020, at 12:53, Kristof Provost  wrote:
> 
> Can you share your kernel config file (and src.conf / make.conf if they 
> exist)?
> 
> This second panic is in the IPSec code. My current thinking is that your 
> kernel config is triggering a bug that’s manifesting in multiple places, but 
> not actually caused by those places.
> 
> I’d like to be able to reproduce it so we can debug it.
> 
> Best regards,
> Kristof
> 
> On 20 Nov 2020, at 12:02, Peter Blo

Re: Commit 367705+367706 causes a pabic

[Peter Blok]

Hi Kristof,

This is 12-stable. With the previous bridge epochification that was backed out 
my config had a panic too.

I don’t have any local modifications. I did a clean rebuild after removing 
/usr/obj/usr

My kernel is custom - I only have zfs.ko, opensolaris.ko, vmm.ko and nmdm.ko as 
modules. Everything else is statically linked. I have removed all drivers not 
needed for the hardware at hand.

My bridge is between two vlans from the same trunk and the jail epair devices 
as well as the bhyve tap devices.

The panic happens when the jails are starting.

I can try to narrow it down over the weekend and make the crash dump available 
for analysis.

Previously I had the following crash with 363492

kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x0410
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80692326
stack pointer   = 0x28:0xfe00c06097b0
frame pointer   = 0x28:0xfe00c06097f0
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 = 2030 (ifconfig)
trap number = 12
panic: page fault
cpuid = 2
time = 1595683412
KDB: stack backtrace:
#0 0x80698165 at kdb_backtrace+0x65
#1 0x8064d67b at vpanic+0x17b
#2 0x8064d4f3 at panic+0x43
#3 0x809cc311 at trap_fatal+0x391
#4 0x809cc36f at trap_pfault+0x4f
#5 0x809cb9b6 at trap+0x286
#6 0x809a5b28 at calltrap+0x8
#7 0x803677fd at ck_epoch_synchronize_wait+0x8d
#8 0x8069213a at epoch_wait_preempt+0xaa
#9 0x807615b7 at ipsec_ioctl+0x3a7
#10 0x8075274f at ifioctl+0x47f
#11 0x806b5ea7 at kern_ioctl+0x2b7
#12 0x806b5b4a at sys_ioctl+0xfa
#13 0x809ccec7 at amd64_syscall+0x387
#14 0x809a6450 at fast_syscall_common+0x101




> On 20 Nov 2020, at 11:30, Kristof Provost  wrote:
> 
> On 20 Nov 2020, at 11:18, peter.b...@bsd4all.org 
>  wrote:
>> I’m afraid the last Epoch fix for bridge is not solving the problem ( or 
>> perhaps creates a new ).
>> 
> We’re talking about the stable/12 branch, right?
> 
>> This seems to happen when the jail epair is added to the bridge.
>> 
> There must be something more to it than that. I’ve run the bridge tests on 
> stable/12 without issue, and this is a problem we didn’t see when the bridge 
> epochification initially went into stable/12.
> 
> Do you have a custom kernel config? Other patches? What exact commands do you 
> run to trigger the panic?
> 
>> kernel trap 12 with interrupts disabled
>> 
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 6; apic id = 06
>> fault virtual address= 0xc10
>> fault code   = supervisor read data, page not present
>> instruction pointer  = 0x20:0x80695e76
>> stack pointer= 0x28:0xfe00bf14e6e0
>> frame pointer= 0x28:0xfe00bf14e720
>> 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  = 1686 (jail)
>> trap number  = 12
>> panic: page fault
>> cpuid = 6
>> time = 1605811310
>> KDB: stack backtrace:
>> #0 0x8069bb85 at kdb_backtrace+0x65
>> #1 0x80650a4b at vpanic+0x17b
>> #2 0x806508c3 at panic+0x43
>> #3 0x809d0351 at trap_fatal+0x391
>> #4 0x809d03af at trap_pfault+0x4f
>> #5 0x809cf9f6 at trap+0x286
>> #6 0x809a98c8 at calltrap+0x8
>> #7 0x80368a8d at ck_epoch_synchronize_wait+0x8d
>> #8 0x80695c8a at epoch_wait_preempt+0xaa
>> #9 0x80757d40 at vnet_if_init+0x120
>> #10 0x8078c994 at vnet_alloc+0x114
>> #11 0x8061e3f7 at kern_jail_set+0x1bb7
>> #12 0x80620190 at sys_jail_set+0x40
>> #13 0x809d0f07 at amd64_syscall+0x387
>> #14 0x809aa1ee at fast_syscall_common+0xf8
> 
> This panic is rather odd. This isn’t even the bridge code. This is during 
> initial creation of the vnet. I don’t really see how this could even trigger 
> panics.
> That panic looks as if something corrupted the net_epoch_preempt, by 
> overwriting the epoch->e_epoch. The bridge patches only access this variable 
> through the well-established functions and macros. I see no obvious way that 
> they could corrupt it.
> 
> Best regards,
> Kristof



smime.p7s
Description: S/MIME cryptographic signature

Commit 367705+367706 causes a pabic

[Peter Blok]

Hi,

I’m afraid the last Epoch fix for bridge is not solving the problem ( or 
perhaps creates a new ).

This seems to happen when the jail epair is added to the bridge.

Removing both fixes solves the problem.

Peter


kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 6; apic id = 06
fault virtual address   = 0xc10
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80695e76
stack pointer   = 0x28:0xfe00bf14e6e0
frame pointer   = 0x28:0xfe00bf14e720
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 = 1686 (jail)
trap number = 12
panic: page fault
cpuid = 6
time = 1605811310
KDB: stack backtrace:
#0 0x8069bb85 at kdb_backtrace+0x65
#1 0x80650a4b at vpanic+0x17b
#2 0x806508c3 at panic+0x43
#3 0x809d0351 at trap_fatal+0x391
#4 0x809d03af at trap_pfault+0x4f
#5 0x809cf9f6 at trap+0x286
#6 0x809a98c8 at calltrap+0x8
#7 0x80368a8d at ck_epoch_synchronize_wait+0x8d
#8 0x80695c8a at epoch_wait_preempt+0xaa
#9 0x80757d40 at vnet_if_init+0x120
#10 0x8078c994 at vnet_alloc+0x114
#11 0x8061e3f7 at kern_jail_set+0x1bb7
#12 0x80620190 at sys_jail_set+0x40
#13 0x809d0f07 at amd64_syscall+0x387
#14 0x809aa1ee at fast_syscall_common+0xf8

smime.p7s
Description: S/MIME cryptographic signature

Re: Commit 364003 causes immediate restart

[Peter Blok]

Hi Alexander,

No problem, this happens and it doesn’t impact me. I try to stay up to date and 
when there is a regression I rollback and narrow it down as an early warning.

Your commit fixed the problem in 364020.

Next time I have a crash and have narrowed it down to a specific commit I’ll 
add the committer again.

Peter



> On 8 Aug 2020, at 21:36, Alexander Motin  wrote:
> 
> Peter,
> 
> I am sorry, there appeared to be a merge mistake in commit 364003. It was 
> fixed in 364020.  Have you tried it? Do you still have a problem after it? If 
> so, please add any more details. 'acpidump -t' would be a good start, same as 
> last output before reboot.
> 
> PS: I don't know about "different committer", but I read mail all the time 
> and appreciate related problem reports.
> 
> 
> On Sat, Aug 8, 2020, 1:49 AM  > wrote:
> Last time I ( a week ago or so ) I did for another crash and wasn’t getting 
> any response from (a different) committer.
> 
> 
> > On 7 Aug 2020, at 21:48, Konstantin Belousov  > > wrote:
> > 
> > On Fri, Aug 07, 2020 at 03:09:00PM +0200, peter.b...@bsd4all.org 
> >  wrote:
> >> Hi,
> >> 
> >> After commit 364003 STABLE-12 reboots almost immediately. No error 
> >> message, not dump. Just a reboot.
> >> 
> >> Last working commit 364002.
> >> 
> >> Please let me know what is needed - acpidump or something like that.
> > Why did not you added the committer to Cc: ?
> > ___
> > freebsd-stable@freebsd.org  mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable 
> > 
> > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org 
> > "
> 

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Commit 364003 causes immediate restart

[Peter Blok]

Hi David,

I was at r346011 when I encountered the problem the first time, so 346007 was 
included. Went back to 346002 => ok. Added 346003 and it failed again.

Peter



> On 7 Aug 2020, at 16:23, David Wolfskill  wrote:
> 
> On Fri, Aug 07, 2020 at 03:09:00PM +0200, peter.b...@bsd4all.org wrote:
>> Hi,
>> 
>> After commit 364003 STABLE-12 reboots almost immediately. No error message, 
>> not dump. Just a reboot.
>> 
>> Last working commit 364002.
>> 
>> Please let me know what is needed - acpidump or something like that.
>> 
> 
> I'm not sure what's needed to diagnose that, but I built:
> 
> FreeBSD g1-55.catwhisker.org 12.1-STABLE FreeBSD 12.1-STABLE #776 
> r364007M/364009: Fri Aug  7 03:36:03 PDT 2020 
> r...@g1-55.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1201522 1201522
> 
> on my laptop this morning, and am running it now without issue.
> 
> So it's possible that updating to r364007 would help.
> 
> (My previous snapshot was:
> 
> FreeBSD g1-55.catwhisker.org 12.1-STABLE FreeBSD 12.1-STABLE #775 
> r363947M/363947: Thu Aug  6 03:34:53 PDT 2020 
> r...@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64 1201522 1201522
> 
> in case that is of use.)
> 
> Peace,
> david
> -- 
> David H. Wolfskillda...@catwhisker.org
> "Knowingly failing to do his job is a hallmark of this presidency and
> we're all less safe because of it." -- Samantha Vinograd
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Commit 364003 causes immediate restart

[peter . blok]

Hi,

After commit 364003 STABLE-12 reboots almost immediately. No error message, not 
dump. Just a reboot.

Last working commit 364002.

Please let me know what is needed - acpidump or something like that.

Peter

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Crash in stable 363430 and higher

[peter . blok]

Hi,

I’m getting the following crash during startup. It seems strongswan is setting 
a reqid.

Commit r363430 is on if_bridge. The IPSec interfaces are not bridged at all, so 
I’m clueless to why this crash relates to this commit. The only commonality is 
that the crash is Epoch related and the commit as well.

(kgdb) list
418  * Propagate our priority to any other waiters to 
prevent us
419  * from starving them. They will have their original 
priority
420  * restore on exit from epoch_wait().
421  */
422 curwaittd = tdwait->et_td;
423 if (!TD_IS_INHIBITED(curwaittd) && 
curwaittd->td_priority > td->td_priority) {
424 critical_enter();
425 thread_unlock(td);
426 thread_lock(curwaittd);
427 sched_prio(curwaittd, td->td_priority);
(kgdb) p/x tdwait
$3 = 0xfe0075dca778
(kgdb) p/x tdwait->et_td
$4 = 0x806
(kgdb) bt
#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:371
#2  0x8064d335 in kern_reboot (howto=260) at 
/usr/src/sys/kern/kern_shutdown.c:451
#3  0x8064d773 in vpanic (fmt=, ap=) at 
/usr/src/sys/kern/kern_shutdown.c:880
#4  0x8064d593 in panic (fmt=) at 
/usr/src/sys/kern/kern_shutdown.c:807
#5  0x809cc3d1 in trap_fatal (frame=0xfe00c8a0e6f0, eva=3094) at 
/usr/src/sys/amd64/amd64/trap.c:925
#6  0x809cc42f in trap_pfault (frame=0xfe00c8a0e6f0, 
usermode=, signo=, ucode=) at 
/usr/src/sys/amd64/amd64/trap.c:743
#7  0x809cba76 in trap (frame=0xfe00c8a0e6f0) at 
/usr/src/sys/amd64/amd64/trap.c:407
#8  
#9  epoch_block_handler_preempt (global=, cr=, 
arg=) at /usr/src/sys/kern/subr_epoch.c:423
#10 0x803677fd in epoch_block (global=0xf800020be600, 
cr=0xfe0075db9a00, cb=0x80692320 , 
ct=0x0) at /usr/src/sys/contrib/ck/src/ck_epoch.c:416
#11 ck_epoch_synchronize_wait (global=0xf800020be600, cb=, 
ct=) at /usr/src/sys/contrib/ck/src/ck_epoch.c:465
#12 0x806921da in epoch_wait_preempt (epoch=0xf800020be600) at 
/usr/src/sys/kern/subr_epoch.c:513
#13 0x80761687 in ipsec_set_reqid (sc=0xf8004261e200, reqid=103) at 
/usr/src/sys/net/if_ipsec.c:964
#14 ipsec_ioctl (ifp=, cmd=, data=) at /usr/src/sys/net/if_ipsec.c:764
#15 0x807527ef in ifioctl (so=0xf8011d766000, cmd=2149607841, 
data=0xfe00c8a0ea10 "btcd", td=) at 
/usr/src/sys/net/if.c:3147
#16 0x806b5f47 in fo_ioctl (fp=0xf800194846e0, com=2149607841, 
data=0x0, active_cred=0x0, td=0xf80122379740) at /usr/src/sys/sys/file.h:337
#17 kern_ioctl (td=0x80692320 , 
fd=, com=2149607841, data=0x0) at 
/usr/src/sys/kern/sys_generic.c:805
#18 0x806b5bea in sys_ioctl (td=0xf80122379740, 
uap=0xf80122379b00) at /usr/src/sys/kern/sys_generic.c:713
#19 0x809ccf87 in syscallenter (td=0xf80122379740) at 
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144
#20 amd64_syscall (td=0xf80122379740, traced=0) at 
/usr/src/sys/amd64/amd64/trap.c:1167
#21 
#22 0x00080044e0da in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffe1a8

Any pointers?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: CFT: if_bridge performance improvements

[peter . blok]

Just using pf is enough to provoke this panic. I had the same back trace. This 
patch from Kristof fixed it for me.

diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c
index 373fa096d70..83c453090bb 100644
--- a/sys/net/if_bridge.c
+++ b/sys/net/if_bridge.c
@@ -2529,7 +2529,6 @@ bridge_input(struct ifnet *ifp, struct mbuf *m)
 OR_PFIL_HOOKED_INET6)) {   \
if (bridge_pfil(, NULL, ifp,  \
PFIL_IN) != 0 || m == NULL) {   \
-   BRIDGE_UNLOCK(sc);  \
return (NULL);  \
}   \
eh = mtod(m, struct ether_header *);\


> On 22 Apr 2020, at 18:15, Xin Li  wrote:
> 
> On 4/22/20 01:45, Kristof Provost wrote:
>> On 22 Apr 2020, at 10:20, Xin Li wrote:
>>> Hi,
>>> 
>>> On 4/14/20 02:51, Kristof Provost wrote:
 Hi,
 
 Thanks to support from The FreeBSD Foundation I’ve been able to work on
 improving the throughput of if_bridge.
 It changes the (data path) locking to use the NET_EPOCH infrastructure.
 Benchmarking shows substantial improvements (x5 in test setups).
 
 This work is ready for wider testing now.
 
 It’s under review here: https://reviews.freebsd.org/D24250
 
 Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
 Patches for stable/12:
 https://people.freebsd.org/~kp/if_bridge/stable_12/
 
 I’m not currently aware of any panics or issues resulting from these
 patches.
>>> 
>>> I have observed the following panic with latest stable/12 after applying
>>> the stable_12 patchset, it appears like a race condition related NULL
>>> pointer deference, but I haven't took a deeper look yet.
>>> 
>>> The box have 7 igb(4) NICs, with several bridge and VLAN configured
>>> acting as a router.  Please let me know if you need additional
>>> information; I can try -CURRENT as well, but it would take some time as
>>> the box is relatively slow (it's a ZFS based system so I can create a
>>> separate boot environment for -CURRENT if needed, but that would take
>>> some time as I might have to upgrade the packages, should there be any
>>> ABI breakages).
>>> 
>> Thanks for the report. I don’t immediately see how this could happen.
>> 
>> Are you running an L2 firewall on that bridge by any chance? An earlier
>> version of the patch had issues with a stray unlock in that code path.
> 
> I don't think I have a L2 firewall (I assume means filtering based on
> MAC address like what can be done with e.g. ipfw?  The bridges were
> created on vlan interfaces though, do they count as L2 firewall?), the
> system is using pf with a few NAT rules:
> 
> $ sudo pfctl -s rules
> anchor "miniupnpd" all
> pass in quick inet6 proto tcp from  to any flags S/SA keep state
> block drop in quick inet6 proto tcp from !  to  flags S/SA
> block drop in quick proto tcp from any os "Linux" to any port = ssh
> pass out on igb6 inet proto tcp from (igb6) to any port = domain flags
> S/SA keep state queue dns
> pass out on igb6 inet proto udp from (igb6) to any port = domain keep
> state queue dns
> pass in on igb6 proto tcp from any to (igb6) port = http flags S/SA
> modulate state queue(web, ack)
> pass in on igb6 proto tcp from any to (igb6) port = https flags S/SA
> modulate state queue(web, ack)
> pass out on igb6 inet proto tcp from (igb6) to any flags S/SA modulate
> state queue bulk
> block drop in quick on igb6 proto tcp from  to any port = ssh
> label "ssh bruteforce"
> block drop in on igb6 from  to any
> 
> Cheers,

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: CFT: if_bridge performance improvements

[peter . blok]

Hi Mark/Kristof,

I have been using ng_bridge for more than a year. It was very stable and it 
allowed to have members with different MTU. My jails were using jng to setup 
the bridge and I changed iohyve to use ng_bridge.

But I recently switched to if_bridge. I needed to have pf work on a member 
interface, which wasn’t easy with ng_bridge. It was not easy to make it work 
due to two members (VLAN) coming frome the same trunk.The behavior was erratic.

I have a trusted VLAN bridged to an untrusted physical and Wifi network. All 
members are on the same IP segment, but with pf I can make sure that the 
untrusted IOT devices are only able to go outside towards the internet. The 
untrusted devices can’t create connections to the trusted devices, but the 
trusted devices can create connections to the untrusted devices.

Another issue I found with pf was with "set skip on bridge”. It doesn’t work on 
the interface group, unless a bridge exists prior to enabling pf. Makes sense, 
but I didn’t think of it. Other rules work fine with interface groups.

My jails and bhyve now runs fine with if_bridge, which is easier to setup and I 
don’t need any changes in iohyve.

Peter 

> On 16 Apr 2020, at 09:44, Kristof Provost  wrote:
> 
> Hi Mark,
> 
> I wouldn’t expect these changes to make a difference in the performance of 
> this setup.
> My work mostly affects setups with multi-core systems that see a lot of 
> traffic. Even before these changes I’d expect the if_bridge code to saturate 
> a wifi link easily.
> 
> I also wouldn’t expect ng_bridge vs. if_bridge to make a significant 
> difference in wifi features.
> 
> Best regards,
> Kristof
> 
> On 16 Apr 2020, at 3:56, Mark Saad wrote:
> 
>> Kristof
>> Up until a month ago I ran a set of FreeBSD based ap in my house and even 
>> long ago at work . They were Pc engines apu ‘s or Alix’s with one em/igb nic 
>> and one ath nic in a bridge .  They worked well for a long time however the 
>> need for more robust wifi setup caused me to swap them  out with cots aps 
>> from tp-link .  The major issues were the lack of WiFi features and 
>> standards that work oob on Linux based aps .
>> 
>> So I always wanted to experiment with ng_bridge vs if_bridge for the same 
>> task . But I never got around to it . Do you have any insight into using one 
>> vs the other . Imho if_bridge is easier to setup and get working .
>> 
>> 
>> ---
>> Mark Saad | nones...@longcount.org
>> 
>>> On Apr 15, 2020, at 1:37 PM, Kristof Provost  wrote:
>>> 
>>> On 15 Apr 2020, at 19:16, Mark Saad wrote:
 All
 Should this improve wifi to wired bridges in some way ? Has this been 
 tested ?
 
>>> What sort of setup do you have to bridge wired and wireless? Is the FreeBSD 
>>> box also a wifi AP?
>>> 
>>> I’ve not done any tests involving wifi.
>>> 
>>> Best regards,
>>> Kristof
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: panic when stopping jails

[peter . blok]

Forgot to mention that it is a very recent 12-STABLE and I don’t suspect any 
recent commits. It is just that jails are now stopped more often.


> On 3 Dec 2019, at 11:47, peter.b...@bsd4all.org wrote:
> 
> Hi,
> 
> I’m getting the following panic when stopping jais. When ifunit_ref iterates 
> over the VNET ifnet’s it gets a bad ifp. I’m using netgrapg bridge’s.
> 
> Any pointers how to debug are welcome. Crash dump is available.
> 
> Peter
> 
> 
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 3; apic id = 03
> instruction pointer   = 0x20:0x807377c5
> stack pointer = 0x28:0xfe00d1e90870
> frame pointer = 0x28:0xfe00d1e90870
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 8537 (ifconfig)
> trap number   = 9
> panic: general protection fault
> cpuid = 3
> time = 1575297301
> KDB: stack backtrace:
> #0 0x8069a8d7 at kdb_backtrace+0x67
> #1 0x8064ec6d at vpanic+0x19d
> #2 0x8064eac3 at panic+0x43
> #3 0x809e450c at trap_fatal+0x39c
> #4 0x809e395a at trap+0x6a
> #5 0x809be97c at calltrap+0x8
> #6 0x80750ff1 at ifunit_ref+0x51
> #7 0x8075328c at ifioctl+0x47c
> #8 0x806b8b2e at kern_ioctl+0x2be
> #9 0x806b87fd at sys_ioctl+0x15d
> #10 0x809e50a2 at amd64_syscall+0x362
> #11 0x809bf2b0 at fast_syscall_common+0x101
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

panic when stopping jails

[peter . blok]

Hi,

I’m getting the following panic when stopping jais. When ifunit_ref iterates 
over the VNET ifnet’s it gets a bad ifp. I’m using netgrapg bridge’s.

Any pointers how to debug are welcome. Crash dump is available.

Peter


Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer = 0x20:0x807377c5
stack pointer   = 0x28:0xfe00d1e90870
frame pointer   = 0x28:0xfe00d1e90870
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 8537 (ifconfig)
trap number = 9
panic: general protection fault
cpuid = 3
time = 1575297301
KDB: stack backtrace:
#0 0x8069a8d7 at kdb_backtrace+0x67
#1 0x8064ec6d at vpanic+0x19d
#2 0x8064eac3 at panic+0x43
#3 0x809e450c at trap_fatal+0x39c
#4 0x809e395a at trap+0x6a
#5 0x809be97c at calltrap+0x8
#6 0x80750ff1 at ifunit_ref+0x51
#7 0x8075328c at ifioctl+0x47c
#8 0x806b8b2e at kern_ioctl+0x2be
#9 0x806b87fd at sys_ioctl+0x15d
#10 0x809e50a2 at amd64_syscall+0x362
#11 0x809bf2b0 at fast_syscall_common+0x101
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: rev 355285 breaks stable build

[peter . blok]

Fixed by rev. 355290

> On 2 Dec 2019, at 16:21, peter.b...@bsd4all.org wrote:
> 
> Hi,
> 
> While building rescue
> 
> ld: error: undefined symbol: lz4_init
 referenced by spa_misc.c:2066 
 (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066)
  spa_misc.o:(spa_init) in archive 
 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a
> 
> ld: error: undefined symbol: lz4_fini
 referenced by spa_misc.c:2096 
 (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096)
  spa_misc.o:(spa_fini) in archive 
 /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [rescue] Error code 1
> 
> Peter
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

rev 355285 breaks stable build

[peter . blok]

Hi,

While building rescue

ld: error: undefined symbol: lz4_init
>>> referenced by spa_misc.c:2066 
>>> (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066)
>>>   spa_misc.o:(spa_init) in archive 
>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a

ld: error: undefined symbol: lz4_fini
>>> referenced by spa_misc.c:2096 
>>> (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096)
>>>   spa_misc.o:(spa_fini) in archive 
>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [rescue] Error code 1

Peter
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Long-shot: repeatable macOS samba share unmounting during Lightroom import

[peter . blok]

The fruit module forces avahi or mdns_responder to be compiled as well. A share 
dispappearing could be due to some interaction with avahi. It could be that the 
combination samba+fruit+avahi and samba+avahi is having different behavior.

Peter



> On 24 Nov 2019, at 12:15, Pete French  wrote:
> 
> I have a very similar setup to you for serving files to my Mac from a FreeBSD 
> server. I haven't seen the unmount problem, but I di have a few oddities 
> until I added the 'fruit' module on the Samba side, which helps with 
> compatbiloty with the Mac. The appropriate bit of my config looks like this:
> 
>   vfs objects = fruit streams_xattr zfsacl
>   fruit:resource = xattr
>   fruit:encoding = private
> 
> Don't ask me what they do anymore, I added them ages ago, but it does work 
> very nicely for me. You may already have this of course, but worth pointing 
> out just in case as it took me a few years to discover it!
> 
> As someone else has said though, this may well be a Catalina bug. I am not 
> running that (MacBook too old, and not buying another until the new keyboards 
> are avilable n the replacement I want).
> 
> -pete.
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Error building stable/12 (amd64) at r355087

[peter . blok]

I can confirm it has been fixed.

> On 25 Nov 2019, at 15:21, Konstantin Belousov  wrote:
> 
> On Mon, Nov 25, 2019 at 03:58:10AM -0800, David Wolfskill wrote:
>> This is during a source-based update from r355048 to r355087, during
>> "stage 4.3: building everything" (using META_MODE); meta file reads:
>> 
>> # Meta data file 
>> /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd/camdd.o.meta
>> CMD cc -target x86_64-unknown-freebsd12.1 
>> --sysroot=/common/S3/obj/usr/src/amd64.amd64/tmp 
>> -B/common/S3/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe   -std=gnu99 
>> -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow 
>> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs 
>> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
>> -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int 
>> -Wno-unused-const-variable  -Qunused-arguments  -c 
>> /usr/src/usr.sbin/camdd/camdd.c -o camdd.o
>> CMD 
>> CWD /common/S3/obj/usr/src/amd64.amd64/usr.sbin/camdd
>> TARGET camdd.o
>> -- command output --
>> In file included from /usr/src/usr.sbin/camdd/camdd.c:54:
>> In file included from 
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus.h:6:
>> In file included from 
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus.h:1043:
>> In file included from 
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/machine/bus_dma.h:34:
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:1: 
>> error: unknown type name 'bool'
>> bool bus_dma_dmar_set_buswide(device_t dev);
>> ^
>> /common/S3/obj/usr/src/amd64.amd64/tmp/usr/include/x86/bus_dma.h:182:31: 
>> error: unknown type name 'device_t'
>> bool bus_dma_dmar_set_buswide(device_t dev);
>>  ^
>> 2 errors generated.
>> 
>> *** Error code 1
> 
> I hope that this is fixed by r355089.  I did not tracked down how HEAD
> was immune to the problem.
> ___
> freebsd-stable@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable 
> 
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org 
> "

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: route based ipsec

[Peter Blok]

I have tried certificates in the past, but racoon never worked stable enough. 
Didn’t crash on me though.

I have moved over to Strongswan and never regretted this move. Very stable.

Peter

> On 8 May 2019, at 03:29, Eugene Grosbein  wrote:
> 
> 08.05.2019 3:23, KOT MATPOCKuH wrote:
> 
>> I'm misunderstand what in my configuration can result core dumps a running
>> daemon...
>> I'm attached a sample racoon.conf. Can You check for possible problems?
>> Also on one host I got a crash in another function:
>> (gdb) bt
>> #0  0x0024717f in privsep_init ()
>> #1  0x002375f4 in inscontacted ()
>> #2  0x002337d0 in isakmp_plist_set_all ()
>> #3  0x0023210d in isakmp_ph2expire ()
>> #4  0x0023162a in isakmp_ph1delete ()
>> #5  0x0023110b in isakmp_ph2resend ()
>> #6  0x0008002aa000 in ?? ()
>> #7  0x in ?? ()
> 
> I guess configuration using certificates is not tested enough.
> It works stable for me but I use psk only.
> 
> You need to fix code yourself or stop using racoon with certificates.
> 
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



smime.p7s
Description: S/MIME cryptographic signature

Re: Observations from a ZFS reorganization on 12-STABLE

[peter . blok]

Same here using mfsbsd from 11-RELEASE. First attempt I forgot to add swap - it 
killed the ssh I was using to issue a zfs send on the remote system.

Next attempt I added swap, but ssh got killed too.

Third attempt I used mfsbsd from 12-RELEASE. It succeeded.

Now I am using mfsbsd 11-RELEASE with added swap and vis.zfs.arc_min and 
arc_max to 128Mb (it is a 4GB system) and it succeeds



> On 18 Mar 2019, at 15:14, Karl Denninger  wrote:
> 
> On 3/18/2019 08:37, Walter Cramer wrote:
>> I suggest caution in raising vm.v_free_min, at least on 11.2-RELEASE
>> systems with less RAM.  I tried "65536" (256MB) on a 4GB mini-server,
>> with vfs.zfs.arc_max of 2.5GB.  Bad things happened when the cron
>> daemon merely tried to run `periodic daily`.
>> 
>> A few more details - ARC was mostly full, and "bad things" was 1:
>> `pagedaemon` seemed to be thrashing memory - using 100% of CPU, with
>> little disk activity, and 2: many normal processes seemed unable to
>> run. The latter is probably explained by `man 3 sysctl` (see entry for
>> "VM_V_FREE_MIN").
>> 
>> 
>> On Mon, 18 Mar 2019, Pete French wrote:
>> 
>>> On 17/03/2019 21:57, Eugene Grosbein wrote:
 I agree. Recently I've found kind-of-workaround for this problem:
 increase vm.v_free_min so when "FREE" memory goes low,
 page daemon wakes earlier and shrinks UMA (and ZFS ARC too) moving
 some memory
 from WIRED to FREE quick enough so it can be re-used before bad
 things happen.
 
 But avoid increasing vm.v_free_min too much (e.g. over 1/4 of total
 RAM)
 because kernel may start behaving strange. For 16Gb system it should
 be enough
 to raise vm.v_free_min upto 262144 (1GB) or 131072 (512M).
 
 This is not permanent solution in any way but it really helps.
>>> 
>>> Ah, thats very interesting, thankyou for that! I;ve been bitten by
>>> this issue too in the past, and it is (as mentioned) much improved on
>>> 12, but the act it could still cause issues worries me.
>>> 
> Raising free_target should *not* result in that sort of thrashing. 
> However, that's not really a fix standing alone either since the
> underlying problem is not being addressed by either change.  It is
> especially dangerous to raise the pager wakeup thresholds if you still
> run into UMA allocated-but-not-in-use not being cleared out issues as
> there's a risk of severe pathological behavior arising that's worse than
> the original problem.
> 
> 11.1 and before (I didn't have enough operational experience with 11.2
> to know, as I went to 12.x from mostly-11.1 installs around here) were
> essentially unusable in my workload without either my patch set or the
> Phabricator one.
> 
> This is *very* workload-specific however, or nobody would use ZFS on
> earlier releases, and many do without significant problems.
> 
> -- 
> Karl Denninger
> k...@denninger.net   >
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: The 11.1-RC3 can only boot and attach disks in "Safe mode", otherwise gets stuck attaching

[Peter Blok]

Same here. EARLY_AP_STARTUP no longer needs to be disabled on my boxes too.


> On 24 May 2018, at 19:12, Mark Martinec  wrote:
> 
> Just a short report to a thread I started when 11.1 came out.
> 
> This machine would stall in a busy loop while attaching disks
> during boot. Rebuilding a kernel with EARLY_AP_STARTUP disabled
> avoided the problem. This was a situation through the whole
> 11.1 life cycle (i.e. patch releases did not help).
> 
> Today I have upgraded this host to 11.2-BETA2, and it is
> no longer necessary to disable EARLY_AP_STARTUP. Good, thanks!
> 
>  Mark
> 
> 
>> 2017-07-20 02:03, Mark Johnston wrote:
>>> One thing to try at this point would be to disable EARLY_AP_STARTUP in
>>> the kernel config. That is, take a configuration with which you're able
>>> to reproduce the hang during boot, and remove "options
>>> EARLY_AP_STARTUP".
>> 2017-07-20 15:45, Mark Martinec wrote:
>> Done. And it avoids the problem altogether! Thanks.
>> Tried a reboot several times and it succeeds every time.
>> Here is all that I had in a config file for building a kernel,
>> i.e. I took away the 'options DDB' which also seemingly avoided
>> the problem:
>>  include GENERIC
>>  ident NELI
>>  nooptions EARLY_AP_STARTUP
>>> This feature has a fairly large impact on the bootup process and has
>>> had a few problems that manifested as hangs during boot. There was at
>>> least one other case where an innocuous change to the kernel
>>> configuration "fixed" the problem by introducing some second-order
>>> effect (causing kernel threads to be scheduled in a different
>>> order, for instance).
> [...]
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



smime.p7s
Description: S/MIME cryptographic signature

Re: 802.1X authenticator for FreeBSD

[Peter Blok]

Although WPA2 enterprise authentication works perfectly on FreeBSD with free 
radius, some functionality (like the built in DHCP) is not implemented due to 
lack of PF_LINK, SOCK_RAW. FreeBSD uses bpf for this.

Don’t know if this is required for what you want, but be aware.

I am interested in switch port authentication, but haven’t found the time to 
dig into the matter. And I refuse to use Linux….

Peter

> On 20 Oct 2017, at 07:32, Peter Ankerstål  wrote:
> 
> 
> 
>> On 18 Oct 2017, at 21:39, Charles Sprickman  wrote:
>> 
>> 
>>> On Oct 18, 2017, at 1:10 PM, Peter Ankerstål  wrote:
>>> 
 
 I’m under the impression that the authenticator function in a wired 
 network is usually part of the switch, and the switch will talk to some 
 authentication server like RADIUS, giving it the port number of the 
 connected device and additional information.
 
 If FreeBSD had such a function, I think it would be limited to 
 point-to-point Ethernet links, 802.1x being a link-layer protocol.
 
>>> 
>>> Yes I know, but this is functional in hostapd for Linux and it would be 
>>> nice to have it in FreeBSD as well. 
>> 
>> I’m not seeing this in FreeBSD, but pfsense does claim to support 802.1x for 
>> wifi.
>> 
>> I just happen to be reading about radius (last I used it was for dialup) for 
>> wifi auth and the quick overview on the radius side of things is that the AP 
>> software sends your auth info as well as MAC and a bunch of other stuff, and 
>> the radius server (much like dialup) sends back all sorts of info beyond 
>> auth success/fail - session timeout, info on what VLAN the client may be on, 
>> firewall policies, etc. Pretty cool stuff.
> 
> 802.1X (or WPA2 Enterprise) works fine with hostapd for wireless in FreeBSD. 
> Well, the authentication at least. I havent tried assigning clients to 
> specific vlans and so on but according to the documentation it is possible.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available)

[Peter Blok]

Marcelo,

This fix solved the problem for RPI-1B. I’ll do some more testing on other RPI 
and nanobsd variants.

Peter

> On 26 Jun 2017, at 16:36, Marcelo Araujo  wrote:
> 
> 
> 
> 2017-06-23 4:02 GMT+08:00 Guido Falsi  >:
> On 06/22/17 19:06, Guido Falsi wrote:
> On 06/22/17 18:38, Warner Losh wrote:
> 
> I'll followup as soon as I have easier use case to reproduce it. I first need 
> to revert to an image affected by the problem.
> 
> I have made a few more tests.
> 
> I am able to trigger this bug easily by running gpart.
> 
> I'm testing on a PCEngines APU2 board with SD memory card.
> 
> # gpart set -a active -i 1 mmcsd0
> active set on mmcsd0s1
> # fsck_ffs -n /dev/mmcsd0s1a
> ** /dev/mmcsd0s1a (NO WRITE)
> ** Last Mounted on /mnt
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> Segmentation fault
> # shutdown -r now
> /sbin/shutdown: Device not configured
> 
> also, if I open another shell I can't perform many other operations which are 
> not failing in the previous root shell:
> 
> > tail /var/log/messages
> /usr/bin/tail: Device not configured.
> 
> 
> BTW while testing this multiple times I also had the root shell segfault 
> while browsing history, so it should be quite easy to reproduce on your side 
> too. running the gpart set command triggers it every time, with slightly 
> different bu always disruptive symptoms.
> 
> There is a chance it only shows with these embedded systems storage 
> controllers though.
> 
> -- 
> Guido Falsi 
> ___
> freebsd...@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs 
> 
> To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org 
> "
> 
> 
> Hi,
> 
> Could you guys test this patch: https://reviews.freebsd.org/D11365 
> ?
> Would it solve the issue?
> 
> Best,
> -- 
> 
> -- 
> Marcelo Araujo(__)
> ara...@freebsd.org  \\\'',)
> http://www.FreeBSD.org    \/  \ ^
> Power To Server. .\. /_)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 11.1-BETA1 Now Available

[Peter Blok]

Hi,

For a while now, I’m not able to build a RPI1-B image from -stable. I have 
narrowed it dow to fix 318394, which adds a refresh option to geom_label. If I 
undo this fix in today’s stable it works ok. If I don’t I’m getting 
continuously:

vm_fault: pager read error, pid 1 (init)
vnode_pager_generic_getpages_done: I/O read error 5

I have looked at the fix and I can’t figure out why it breaks the code.

And yes I have tried various other SD cards - they all have the same issue.

Peter


> On 12 Jun 2017, at 23:02, Ed Maste  wrote:
> 
> On 12 June 2017 at 00:43, Warner Losh  wrote:
>> 
>> aarch64 support isn't completely integrated into FreeBSD 11 yet.
> 
> A clarification: arm64/aarch64 support has been available as of
> FreeBSD 11.0 for Cavium ThunderX, and the SoftIron arm64 hardware is
> also supported now.
> 
> What we don't have yet is a project-produced SD card image for
> Raspberry Pi 3; until that happens you can use an image from
> raspbsd.org.
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 11.1-BETA1 Now Available

[peter . blok]

Hi,

For a while now, I’m not able to build a RPI1-B image from -stable. I have 
narrowed it dow to fix 318394, which adds a refresh option to geom_label. If I 
undo this fix in today’s stable it works ok. If I don’t I’m getting 
continuously:

vm_fault: pager read error, pid 1 (init)
vnode_pager_generic_getpages_done: I/O read error 5

I have looked at the fix and I can’t figure out why it breaks the code.

And yes I have tried various other SD cards - they all have the same issue.

Peter


> On 12 Jun 2017, at 23:02, Ed Maste  wrote:
> 
> On 12 June 2017 at 00:43, Warner Losh  wrote:
>> 
>> aarch64 support isn't completely integrated into FreeBSD 11 yet.
> 
> A clarification: arm64/aarch64 support has been available as of
> FreeBSD 11.0 for Cavium ThunderX, and the SoftIron arm64 hardware is
> also supported now.
> 
> What we don't have yet is a project-produced SD card image for
> Raspberry Pi 3; until that happens you can use an image from
> raspbsd.org.
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: USB problems after r316423 (LLVM-4.0)

[peter . blok]

Kevin,

Haven’t noticed anything unusual with USB. Just have tried other things like 
USB stick, USB cdrom and USB ethernet, both on USB2.0 and USB3.0 but no issues

xhci0:  mem 0xf750-0xf750 irq 16 
at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
xhci0: Port routing mask set to 0x
usbus0 on xhci0
ehci0:  mem 0xf7513000-0xf75133ff 
irq 16 at device 26.0 on pci0
usbus1 on ehci0
ehci1:  mem 0xf7512000-0xf75123ff 
irq 22 at device 29.0 on pci0
usbus2 on ehci1
xhci0:  mem 0xf750-0xf750 irq 16 
at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
xhci0: Port routing mask set to 0x
usbus0 on xhci0
ehci0:  mem 0xf7513000-0xf75133ff 
irq 16 at device 26.0 on pci0
usbus1 on ehci0
ehci1:  mem 0xf7512000-0xf75123ff 
irq 22 at device 29.0 on pci0
usbus2 on ehci1

Peter
> On 18 Apr 2017, at 21:53, Kevin Oberman  wrote:
> 
> USB on my system (Lenovo T520-Cougar Point chipset) fails to initialize. I
> have reported this in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218513
> 
> Can others running 11-STABLE at or after r316423 confirm the operation of
> USB ports? It seems unlikely that I am the only one seeing this as my
> system is pretty vanilla, but I have seen no other reports.
> 
> If you have such a system, can you either confirm that USB is working or
> test by plugging in any USB device and seeing if it shows up or check
> /var/run/dmesg for the errors reported in the ticket?
> 
> I am running GENERIC except for SCHED_4BSD. (I tried SCHED_ULE with no
> change.)
> CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (2491.97-MHz K8-class CPU)
>  Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
> Other details are in the ticket.
> 
> Thanks so much.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

panic in pfcioctl

[Peter Blok]

Hi,

I’m running 11-STABLE rev 316522.

I recently had a panic while doing a pfctl -f /etc/pf.conf


The panic happens on LIST_REMOVE in keg_fetch_slab

static uma_slab_t
keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags)
{
uma_slab_t slab;
int reserve;

mtx_assert(>uk_lock, MA_OWNED);
slab = NULL;
reserve = 0;
if ((flags & M_USE_RESERVE) == 0)
reserve = keg->uk_reserve;

for (;;) {
/*
 * Find a slab with some space.  Prefer slabs that are partially
 * used over those that are totally full.  This helps to reduce
 * fragmentation.
 */
if (keg->uk_free > reserve) {
if (!LIST_EMPTY(>uk_part_slab)) {
slab = LIST_FIRST(>uk_part_slab);
} else {
slab = LIST_FIRST(>uk_free_slab);
LIST_REMOVE(slab, us_link);
LIST_INSERT_HEAD(>uk_part_slab, slab,
us_link);
}
MPASS(slab->us_keg == keg);
return (slab);
}

KDB: stack backtrace:
#0 0x805df0e7 at kdb_backtrace+0x67
#1 0x8059d176 at vpanic+0x186
#2 0x8059cfe3 at panic+0x43
#3 0x808ebaa2 at trap_fatal+0x322
#4 0x808ebaf9 at trap_pfault+0x49
#5 0x808eb336 at trap+0x286
#6 0x808d1441 at calltrap+0x8
#7 0x808a871e at zone_fetch_slab+0x6e
#8 0x808a87cd at zone_import+0x4d
#9 0x808a4fc9 at uma_zalloc_arg+0x529
#10 0x80803214 at pfr_ina_define+0x584
#11 0x807f0734 at pfioctl+0x3364
#12 0x80469288 at devfs_ioctl_f+0x128
#13 0x805fa925 at kern_ioctl+0x255
#14 0x805fa65f at sys_ioctl+0x16f
#15 0x808ec604 at amd64_syscall+0x6c4
#16 0x808d172b at Xfast_syscall+0xfb

The panic is not reproducible.

So far the 1st time I stop a jail I get (numbers vary)

kernel: Freed UMA keg (pf table entries) was not empty (32 items).  Lost -57 
pages of memory.

Any tips on how to debug/avoid this?


Peter
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

setting pci pnp SMC2602W

[Peter Blok]

I am running 4.3-STABLE, version of 2 july. I have a SMC2602W card (PCI to
PCMCIA bridge to SMC2632W) wireless LAN adapter. The kernel recognizes the
adapter, bit fails to allocate an interrupt No irq?! message because the
IRQ is already occupied. The if_wi driver doesn't allow RF_SHAREABLE irqs.

How can I force an interrupt to the value I want?


Peter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: DDB watch

[Peter . Blok]

The location was ok. I suddenly realize it was on a dual cpu system. Could SMP break 
the watch behavior?
 On Sunday, 25 February 2001 at 22:52:11 +0100, Peter Blok wrote:
  Hi,
 
  I was trying to setup a "watch" in DDB. When it hits it, the kernel
  reboots.  Am I doing something wrong or isn't it working. I start up
  with boot -d set a breakpoint somewhere, hits breakpoint and set
  watchpoint. After the continue it crashes, without a backtrace. Just
  a black screen and reboot.
 
 There are places where you can't set a breakpoint.  An obvious place
 is in the ddb code: if you hit a breakpoint there, you're going to
 recurse to the top of the stack and crash.  There are other less
 obvious places, and I suspect that's what you have hit.
 
 Greg
 --
 Finger [EMAIL PROTECTED] for PGP public key
 See complete headers for address and phone numbers

RE: 802.1q vlans and STABLE

[Peter Blok]

I am working with VLANs and a BayStack 450-T without stability problems,
except when you configure NETGRAPH at the same time. The kernel crashes
during boot-up.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Mike Tancsa
Sent: Friday, February 23, 2001 04:13
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: 802.1q vlans and STABLE


Hi,
are vlans and the fxp driver ready for prime time ? I have a situation
where I would like to deploy a simple network which looks like


[network vlan #1]-[cat5500]-[network vlan #2]
  |
  |
  |
[freebsd fxp0]

The two remote networks would be trunked back to me using 802.1q encaps off
a cat 5500 switch.  I am using the patch at
http://www.euitt.upm.es/~pjlobo/fbsdvlan.html

to account for larger frame sizes. Whats not clear to me is that when
configuring fxp0, do I just assign it IPs via the vlan interface, or should
I also give fxp0 a normal IP.  Will it break things if fxp0 has an IP
associated with it ?

Also, does aliasing of vlan interfaces work as expected ?

if network #1 was 10.20.30.1/24 and 10.30.40.1/24 on vlan #123

and

network #2 was 172.16.1.1/24 and 192.168.1.1/24 on vlan #456

do I just do

ifconfig fxp0 up
ifconfig vlan0 inet 10.20.30.1 netmask 255.255.255.0 vlan 123 vlandev fxp0
mtu 1500
ifconfig vlan0 inet 10.30.40.1 netmask 255.255.255.0 alias


ifconfig vlan1 


Is there a limit as to the # of vlan interfaces ?  Also, do I have any
performance hits if I have too many vlans ?  If I recall correctly, in
LINUX, there used to be a performance hit if you had too many interfaces.



Mike Tancsa,  tel +1 519 651 3400
Network Administration,   [EMAIL PROTECTED]
Sentex Communications www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message