Re: 12.0-RELEASE zfs/vnode deadlock issue
> On Mar 1, 2019, at 7:00 AM, Nick Rogers wrote: > > I am hoping someone can help me figure out if this is a legitimate bug, or > something already fixed in 12-STABLE. I wish I could reproduce it reliably > to try against STABLE, but there doesn't appear to be any related ZFS fixes > not in RELEASE. Thanks. > I have also experienced this problem, but I haven’t been able to troubleshoot it at all. 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: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic
Lee Damon wrote on 2019/03/02 01:36: On 3/1/19 15:38 , Miroslav Lachman wrote: Did you tried to boot "safe mode"? (selectable in boot menu). I completely forgot about safe mode. Yep. It boots. I'm going to finish the freebsd-update process then reboot into safe mode again. I'm out of time to work on this today and am only in this lab on Fridays so I'll have to pick up working on this problem next Friday. Glad to know something finally works :) You can look in to /boot/menu-commands.4th there is definition what Safe Mode disable : safemode_enabled? ( -- flag ) s" kern.smp.disabled" getenv -1 <> dup if swap drop ( c-addr flag -- flag ) then ; : 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 ; You can play with these items one by one to find what is the root cause in your case. Miroslav Lachman ___ 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: 12.0-RELEASE zfs/vnode deadlock issue
On 01/03/2019 17:00, Nick Rogers wrote: > 36704 101146 perl- mi_switch+0xe1 > sleepq_wait+0x2c sleeplk+0x1c5 lockmgr_xlock_hard+0x19c VOP_LOCK1_APV+0x7e > _vn_lock+0x40 zfs_znode_alloc+0x434 zfs_mknode+0xa9d > zfs_freebsd_create+0x512 VOP_CREATE_APV+0x78 vn_open_cred+0x2c9 > kern_openat+0x20c amd64_syscall+0x369 fast_syscall_common+0x101 I suspect that this thread is a root cause of the problem. In this place, the vnode should be freshly created and not visible to anything but the current thread. So, vn_lock() should always immediately succeed. I cannot understand how the vnode lock could be held by another thread. -- Andriy Gapon ___ 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"
EHCI interrupt storm (~24000 per second) on 12.0 (Lynx Point chipset)
I have an Intel Server board (it's a UEFI Development Kit system, based on the S1200V3RPS) that I recently upgraded to 12.0-RELEASE, and today noticed the intr task taking up too much CPU time. I can't say whether this is a regression from 11.x or not. Looking at the output of "vmstat -i" there appears to be an interrupt storm: bcran@muon:~ % vmstat -i interrupt total rate irq4: uart0 248 4 irq16: ehci0 147 2 irq23: ehci1 1689451 24000 cpu0:timer 6398 91 cpu1:timer 3696 53 cpu2:timer 2246 32 cpu3:timer 2386 34 cpu4:timer 3152 45 cpu5:timer 2341 33 cpu6:timer 75101 1067 cpu7:timer 1646 23 irq265: igb0:rxq0 118 2 irq266: igb0:rxq1 133 2 irq267: igb0:rxq2 17 0 irq268: igb0:rxq3 259 4 irq269: igb0:aq 2 0 irq270: igb1:rxq0 2 0 irq275: ahci0 17450 248 Total 1804793 25639 This is after I tried setting hw.usb.ehci.lostintrbug=1 in /boot/loader and rebooting. The USB devices connected are: bcran@muon:~ % sudo usbconfig ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.3: FW:L9> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (2mA) dmesg shows it being a Lynx Point USB controller: ehci1: mem 0xc2b29000-0xc2b293ff at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 usbus1: 480Mbps High Speed USB v2.0 Strangely, em0 is failing to attach, but I guess that's unrelated? em0: port 0x5040-0x505f mem 0xc2b0-0xc2b1,0xc2b2b000-0xc2b2bfff at device 25.0 on pci0 em0: attach_pre capping queues at 1 em0: Setup of Shared code failed, error -2 em0: IFDI_ATTACH_PRE failed 6 device_attach: em0 attach returned 6 -- Rebecca Cran ___ 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"
