Re: ZFS rename with associated snapshot present: odd error message
On 05/05/2021 01:59, Mark Millard via freebsd-current wrote: I had a: # zfs list -tall NAME USED AVAIL REFER MOUNTPOINT . . . zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G - 1.44G -. . . . . . (copied/pasted from somewhat earlier) and then attempted: # zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style': snapshot delimiter '@' is not expected here Despite the "cannot open" message, the result looks like: # zfs list -tall NAME USED AVAIL REFER MOUNTPOINT . . . zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0 zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0@dirty-style 1.44G - 1.44G - . . . Still, it leaves me wondering if everything is okay given that internal attempt to use the old name with @dirty-style when it was apparently no longer available under that naming. For reference: # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 Cannot reproduce here (but with much simpler names and on stable/13): zfs create testz/test zfs snapshot testz/test@snap1 zfs rename testz/test testz/test2 All worked. -- 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"
Re: stable/13, vm page counts do not add up
On 14/04/2021 16:32, Mark Johnston wrote:
On Wed, Apr 14, 2021 at 02:21:44PM +0300, Andriy Gapon wrote:
On 14/04/2021 00:18, Mark Johnston wrote:
fbt::vm_page_unwire:entry
/args[0]->oflags & 0x4/
{
@unwire[stack()] = count();
}
Unrelated report, dtrace complains about this probe on my stable/13 system:
failed to resolve translated type for args[0]
And I do not have any idea why...
There was a regression, see PR 253440. I think you have the fix
already, but perhaps not. Could you show output from
"dtrace -lv -n fbt::vm_page_unwire:entry"?
dtrace -lv -n fbt::vm_page_unwire:entry
ID PROVIDERMODULE FUNCTION NAME
54323fbtkernelvm_page_unwire entry
Probe Description Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: Unknown
Argument Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Types
args[0]: (unknown)
args[1]: (unknown)
It seems that I should have the fix, but somehow I still have the problem.
I've been doing NO_CLEAN builds for a long while, so maybe some stale file
didn't get re-created...
It looks that dt_lex.c under /usr/obj is rather dated.
... I've removed that file and rebuilt libdtrace and everything is okay now.
Thank you.
From ctfdump:
[27290] FUNC (vm_page_unwire) returns: 38 args: (1463, 3)
<1463> TYPEDEF vm_page_t refers to 778
<778> POINTER (anon) refers to 3575
<3575> STRUCT vm_page (104 bytes)
plinks type=3563 off=0
listq type=3558 off=128
object type=3564 off=256
pindex type=3565 off=320
phys_addr type=42 off=384
md type=3571 off=448
ref_count type=31 off=640
busy_lock type=31 off=672
a type=3573 off=704
order type=3 off=736
pool type=3 off=744
flags type=3 off=752
oflags type=3 off=760
psind type=2167 off=768
segind type=2167 off=776
valid type=3574 off=784
dirty type=3574 off=792
--
Andriy Gapon
--
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"
Re: stable/13, vm page counts do not add up
On 14/04/2021 00:18, Mark Johnston wrote:
fbt::vm_page_unwire:entry
/args[0]->oflags & 0x4/
{
@unwire[stack()] = count();
}
Unrelated report, dtrace complains about this probe on my stable/13 system:
failed to resolve translated type for args[0]
And I do not have any idea why...
From ctfdump:
[27290] FUNC (vm_page_unwire) returns: 38 args: (1463, 3)
<1463> TYPEDEF vm_page_t refers to 778
<778> POINTER (anon) refers to 3575
<3575> STRUCT vm_page (104 bytes)
plinks type=3563 off=0
listq type=3558 off=128
object type=3564 off=256
pindex type=3565 off=320
phys_addr type=42 off=384
md type=3571 off=448
ref_count type=31 off=640
busy_lock type=31 off=672
a type=3573 off=704
order type=3 off=736
pool type=3 off=744
flags type=3 off=752
oflags type=3 off=760
psind type=2167 off=768
segind type=2167 off=776
valid type=3574 off=784
dirty type=3574 off=792
--
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"
Re: stable/13, vm page counts do not add up
On 07/04/2021 23:56, Mark Johnston wrote: > I don't know what might be causing it then. It could be a page leak. > The kernel allocates wired pages without adjusting the v_wire_count > counter in some cases, but the ones I know about happen at boot and > should not account for such a large disparity. I do not see it on a few > systems that I have access to. Mark or anyone, do you have a suggestion on how to approach hunting for the potential page leak? It's been a long while since I worked with that code and it changed a lot. Here is some additional info. I had approximately 2 million unaccounted pages. I rebooted the system and that number became 20 thousand which is more reasonable and could be explained by those boot-time allocations that you mentioned. After 30 hours of uptime the number became 60 thousand. I monitored the number and so far I could not correlate it with any activity. P.S. I have not been running any virtual machines. I do use nvidia graphics driver. -- 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"
Re: stable/13, vm page counts do not add up
On 07/04/2021 22:54, Mark Johnston wrote: > On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote: >> >> I regularly see that the top's memory line does not add up (and by a lot). >> That can be seen with vm.stats as well. >> >> For example: >> $ sysctl vm.stats | fgrep count >> vm.stats.vm.v_cache_count: 0 >> vm.stats.vm.v_user_wire_count: 3231 >> vm.stats.vm.v_laundry_count: 262058 >> vm.stats.vm.v_inactive_count: 3054178 >> vm.stats.vm.v_active_count: 621131 >> vm.stats.vm.v_wire_count: 1871176 >> vm.stats.vm.v_free_count: 18 >> vm.stats.vm.v_page_count: 8134982 >> >> $ bc >>>>> 18 + 1871176 + 621131 + 3054178 + 262058 >> 5996320 >>>>> 8134982 - 5996320 >> 2138662 >> >> As you can see, it's not a small number of pages either. >> Approximately 2 million pages, 8 gigabytes or 25% of the whole memory on this >> system. >> >> This is 47c00a9835926e96, 13.0-STABLE amd64. >> I do not think that I saw anything like that when I used (much) older >> FreeBSD. > > One relevant change is that vm_page_wire() no longer removes pages from > LRU queues, so the count of pages in the queues can include wired pages. > If the page daemon runs, it will dequeue any wired pages that are > encountered. Maybe I misunderstand how that works, but I would expect that the sum of all counters could be greater than v_page_count at times. But in my case it's less. > This was done to reduce queue lock contention, operations like > sendfile() which transiently wire pages would otherwise trigger two > queue operations per page. Now that queue operations are batched this > might not be as important. > > We could perhaps add a new flavour of vm_page_wire() which is not lazy > and would be suited for e.g., the buffer cache. What is the primary > source of wired pages in this case? It should be ZFS, I guess. -- 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"
stable/13, vm page counts do not add up
I regularly see that the top's memory line does not add up (and by a lot). That can be seen with vm.stats as well. For example: $ sysctl vm.stats | fgrep count vm.stats.vm.v_cache_count: 0 vm.stats.vm.v_user_wire_count: 3231 vm.stats.vm.v_laundry_count: 262058 vm.stats.vm.v_inactive_count: 3054178 vm.stats.vm.v_active_count: 621131 vm.stats.vm.v_wire_count: 1871176 vm.stats.vm.v_free_count: 18 vm.stats.vm.v_page_count: 8134982 $ bc >>> 18 + 1871176 + 621131 + 3054178 + 262058 5996320 >>> 8134982 - 5996320 2138662 As you can see, it's not a small number of pages either. Approximately 2 million pages, 8 gigabytes or 25% of the whole memory on this system. This is 47c00a9835926e96, 13.0-STABLE amd64. I do not think that I saw anything like that when I used (much) older FreeBSD. -- 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"
Re: kldload zfs spins the system after upgrading from 12.2 to 13-BETA
On 20/03/2021 05:01, Yoshihiro Ota wrote:
> On Tue, 9 Mar 2021 11:24:53 +0200
> Andriy Gapon wrote:
>
>> On 08/03/2021 05:24, Yoshihiro Ota wrote:
>>> On Sun, 7 Mar 2021 00:09:33 +0200
>>> Andriy Gapon wrote:
>>>
>>>> On 06/03/2021 20:09, Yoshihiro Ota wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm upgrading fron 12.2-RELEASE to 13-BETA/RC one by one.
>>>>>
>>>>> After upgrading one in VMWare, 'zfs mount -a' hangs the system.
>>>>> I don't have boottime zfs mount on nor don't have zfsroot.
>>>>> I just simply ran install world/kernel and mergemaster.
>>>>
>>>> Please use procstat -kk to capture a kernel stack trace of the hung
>>>> process.
>>>
>>> Actually, spining was 'kldload zfs'.
>>> Console doesn't response but ping and sshd sessions still work.
>>> procstat output is below.
>>> In addition, this doesn't happen to systems that I've been following
>>> 13-CURRENT
>>> but rather happen only wiht a system upgraded from 12.2-RELEASE to 13-RC.
>>>
>>>
>>> # procstat -kk 1049
>>> PIDTID COMMTDNAME KSTACK
>>>
>>> 1049 100215 kldload - spa_init+0xc6
>>> zfs_kmod_init+0x1a
>>> zfs_modevent+0x34 module_register_init+0x8c linker_load_module+0xaab
>>> kern_kldload+0xc1
>>> sys_kldload+0x50 syscall+0x17d g_ctx+0xe280bf29
>>>
>>
>> If you could use kgdb to find out what source code line spa_init+0xc6
>> corresponds to that may help to see what's going on.
>>
>
> It look me a while to get kgdb working properly.
> At last, I got the output.
> It looks it is spining on a mutex.
>
> I have few other machines run the same kernel but they can load zfs.ko.
> It is only vmware VM that spins with 'kldload zfs'.
>
> vmware# kgdb101 /usr/usr/lib/debug/boot/kernel/zfs.ko.debug
> GNU gdb (GDB) 10.1 [GDB v10.1 for FreeBSD]
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "i386-portbld-freebsd13.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "helpType "apropos word" to search for commands related to
> "word"...
> Reading symbols from zfs.ko.debug...
> (kgdb) info line *spa_init+0xc6
> Line 2345 of "/usr/src/sys/contrib/openzfs/module/zfs/spa_misc.c"
>starts at address 0x2b0461
>and ends at 0x2b0467 .
> (kgdb)
>
> void
> spa_init(spa_mode_t mode)
> {
> mutex_init(_namespace_lock, NULL, MUTEX_DEFAULT, NULL);
> mutex_init(_spare_lock, NULL, MUTEX_DEFAULT, NULL); // <- line
> 2345
>
It would highly unusual (and unexplainable) for a thread to get stuck here.
Are you sure that your source tree matches the binary?
Can you disassemble the function to check instructions at and near 0xc6 offset?
--
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"
Re: kldload zfs spins the system after upgrading from 12.2 to 13-BETA
On 08/03/2021 05:24, Yoshihiro Ota wrote: > On Sun, 7 Mar 2021 00:09:33 +0200 > Andriy Gapon wrote: > >> On 06/03/2021 20:09, Yoshihiro Ota wrote: >>> Hi all, >>> >>> I'm upgrading fron 12.2-RELEASE to 13-BETA/RC one by one. >>> >>> After upgrading one in VMWare, 'zfs mount -a' hangs the system. >>> I don't have boottime zfs mount on nor don't have zfsroot. >>> I just simply ran install world/kernel and mergemaster. >> >> Please use procstat -kk to capture a kernel stack trace of the hung process. > > Actually, spining was 'kldload zfs'. > Console doesn't response but ping and sshd sessions still work. > procstat output is below. > In addition, this doesn't happen to systems that I've been following > 13-CURRENT > but rather happen only wiht a system upgraded from 12.2-RELEASE to 13-RC. > > > # procstat -kk 1049 > PIDTID COMMTDNAME KSTACK > > 1049 100215 kldload - spa_init+0xc6 > zfs_kmod_init+0x1a zfs_modevent+0x34 module_register_init+0x8c > linker_load_module+0xaab kern_kldload+0xc1 sys_kldload+0x50 syscall+0x17d > g_ctx+0xe280bf29 > If you could use kgdb to find out what source code line spa_init+0xc6 corresponds to that may help to see what's going on. -- 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"
Re: zfs mount -a spins the system after upgrading from 12.2 to 13-BETA
On 06/03/2021 20:09, Yoshihiro Ota wrote: > Hi all, > > I'm upgrading fron 12.2-RELEASE to 13-BETA/RC one by one. > > After upgrading one in VMWare, 'zfs mount -a' hangs the system. > I don't have boottime zfs mount on nor don't have zfsroot. > I just simply ran install world/kernel and mergemaster. Please use procstat -kk to capture a kernel stack trace of the hung process. -- 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"
Re: Trying do mount a slice containing a r/o mounted partition makes the filesystem unreadable
On 02/03/2021 09:50, Arrigo Marchiori via freebsd-stable wrote: > Dear All, > > On Sat, Feb 27, 2021 at 04:34:52PM +0100, Arrigo Marchiori via freebsd-stable > wrote: > >> Hello Helge, and thank you for replying again. >> >> On Sat, Feb 27, 2021 at 03:43:52PM +0100, Helge Oldach wrote: >> >>> Arrigo Marchiori via freebsd-stable wrote on Sat, 27 Feb 2021 14:00:24 >>> +0100 (CET): >>>> On the memstick, the root filesystem is mounted read-only. I >>>> apologize, I should have told it explicitly. The ``invalid'' attempt >>>> is to mount it read-write (no mode is indicated on the command line). >>> >>> Try to make it r/w mounted (which I suspect you are attempting to >>> achieve): >>> >>> mount -uw / >> >> Ok, I will try this. >> >> But just for the record: I am not try to achieve anything. I gave the >> ``invalid'' mount command by mistake (I wanted to mount a partition >> from another disk and wrote "da0" instead of "da1") and I saw that the >> system became unstable. I thought that this should not happen and I >> reported it here. > > I have two updates. > > 1- the da0s2a slice starts 16 (blocks?) after the beginning of da0s2. > bsdlabel(8) output (copied by hand): > # /dev/da0s2: > 8 partitions: > # size offsetfstype[fsize bsize bps/cpg] > a: 1491200 164.2BSD 0 0 0 > c: 1491216 0unused 0 0 # "raw" part, don't > edit > > 2- if I mount the partition rw, then the mount command _always_ fails > with error "operation not permitted" and the system _always_ remains > stable. This is independent from mounting from /dev/ufs/label or > /dev/da0s2a. > > Therefore I can change the description of this problem report as: > > 8<8<8<8<8<8<8<- > > When a BSD partition is mounted _read_only_ to / (suppose > /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I > receive a ``strange'' error message, and from that moment the mounted > filesystem becomes unreadable. > > - If the partition is mounted from /dev/ufs/label, then mount(8) > reports "Operation not permitted" and the system remains stable. > This is the expected behavior IMHO. > > - If the partition is mounted read_write, from any special device, >then mount(8) reports: > - "Operation not permitted" if I try to mount the slice rw, > - the same strange error message if I try to mount the slice ro, >and the system remains stable. > > - The "strange error message" is "invalid argument" on 11.4-STABLE. > > 8<8<8<8<8<8<8<- > > Now to the question: is this worth a PR? Was it already reported? Or > is it just something that ``should not happen'' because root should be > allowed to shoot themselves in the foot? > > Thank you in advance and best regards, I think that this is worth a PR. I think that even when mounting read-only the underlying GEOM object should be marked for exclusive use. I vaguely recall that UFS has some quirk in this respect to allow for modifications by fsck. That is supposed to be limited to the root filesystem. Maybe it should further be limited to certain boot stages to prevent foot-shooting after a system is fully booted. -- 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"
Re: Any way to get hsm(4) device under stable/12?
On 28/02/2021 20:12, David Wolfskill wrote: > Various devices under src/sys/dev/hid are available in base under > stable/13 and head; are they available in some way under stable/12? Yes, they are part of iichid package. -- 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"
Re: uchcom update
On 28/02/2021 11:03, KOT MATPOCKuH wrote: > Hello! > > I'm using FreeBSD 12.2-STABLE r368656 and got usb-to-rs232 with this > controller. > I see /dev/cuaU0 after plugging in adapter, I can attach to serial line > using cu, but after sending any symbol to device I have device reconnection: > uchcom0 on uhub0 > uchcom0: on usbus0 > uchcom0: CH340 detected > uchcom0: at uhub0, port 9, addr 17 (disconnected) > uchcom0: detached > uchcom0 on uhub0 > uchcom0: on usbus0 > uchcom0: CH340 detected I have this in my loader.conf: # Ignore result of "clear stall" (clearing halt on endpoints) # CH340 USB<->RS232 requires this # and it seems that Linux and Windows do this by default hw.usb.no_cs_fail=1 I recall that without that tuning I had a similar problem. > вт, 5 июн. 2018 г. в 15:05, Ian FREISLICH : > >> On 05/22/2018 09:44 AM, Andriy Gapon wrote: >>> Yesterday I committed some changes to uchcom (so far, only in CURRENT). >>> Commits are r333997 - r334002. >>> >>> If you have a CH340/341 based USB<->RS232 adapter and it works for you, >> could >>> you please test that it still does? >>> If you tried your adapter in the past and it did not work, there is a >> chance it >>> might start working now. Could you please test that as well? >> >> ugen5.4: at usbus5, cfg=0 md=HOST spd=FULL >> (12Mbps) pwr=ON (96mA) >> ugen5.4.0: uchcom0: >> >> It's not made it any worse. I'm not using this adapter by choice - it's >> a USB to Maxim (Dallas) one-wire bus adapter. The manual used to state >> that these are possibly the worst chips ever. Is that still the >> prevailing opinion? -- 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"
Re: lots of "no such file or directory" errors in zfs filesystem
On 23/02/2021 05:25, Chris Anderson wrote: > so I can't ls -i the file since that triggers the no such file warning. if I > run > zdb - on the inode of a directory which contains one of those missing > files, > I can get the inode of the file from that, but I don't get anything > particularly > interesting in the output. > > most of the files that are missing are in directories with a large number of > files (the largest has 180k) but I managed to find a directory which had a > single file entry that is missing: > > Dataset tank/home/cva [ZPL], ID 196, cr_txg 163, 109G, 908537 objects, rootbp > DVA[0]=<0:13210311000:1000> DVA[1]=<0:18b9a02c000:1000> [L0 DMU objset] > fletcher4 uncompressed LE contiguous unique double size=800L/800P > birth=46916371L/46916371P fill=908537 > cksum=11fdd21d1d:13cb24c87a6e:da0c9bf1b5df3:715ab2ec45b7b09 > > > Object lvl iblk dblk dsize dnsize lsize %full type > > 38268 1 128K 1K 0 512 1K 100.00 ZFS directory > > 264 bonus ZFS znode > > dnode flags: USED_BYTES USERUSED_ACCOUNTED > > dnode maxblkid: 0 > > uid 1001 > > gid 1001 > > atime Sun Aug 6 02:00:41 2017 > > mtime Wed Apr 15 12:12:42 2020 > > ctime Wed Apr 15 12:12:42 2020 > > crtime Sat Aug 5 15:10:07 2017 > > gen 23881023 > > mode 40755 > > size 3 > > parent 38176 > > links 2 > > pflags 4080144 > > xattr 0 > > rdev 0x > > microzap: 1024 bytes, 1 entries > > > > hash_test.go = 38274 (type: Regular File) > > > # zdb - tank/home/cva 38274 > > Dataset tank/home/cva [ZPL], ID 196, cr_txg 163, 109G, 908537 objects, rootbp > DVA[0]=<0:13210311000:1000> DVA[1]=<0:18b9a02c000:1000> [L0 DMU objset] > fletcher4 uncompressed LE contiguous unique double size=800L/800P > birth=46916371L/46916371P fill=908537 > cksum=11fdd21d1d:13cb24c87a6e:da0c9bf1b5df3:715ab2ec45b7b09 > > > Object lvl iblk dblk dsize dnsize lsize %full type > > zdb: dmu_bonus_hold(38274) failed, errno 2 So, this looks like a "simple" problem. Unfortunately, it is very hard to tell retrospectively what bug caused it. The directory has an entry for the file, but the file does not actually exist (or has a different ID). This is a logical inconsistency, not a data integrity issue. So, a scrub, being a data integrity check, would not detect such an issue. Hypothetical zfs_fsck is needed to find and repair such logical problems. Does that pool and filesystem have any special history? I mean upgrades, replication via send/recv, moving between OS-s, etc. -- 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"
Re: lots of "no such file or directory" errors in zfs filesystem
On 22/02/2021 16:20, Chris Anderson wrote: > On Mon, Feb 22, 2021 at 1:36 AM Andriy Gapon <mailto:a...@freebsd.org>> wrote: > > On 22/02/2021 09:31, Chris Anderson wrote: > > None of these files are especially important to me, however I was > wondering > > if there would be any benefit to the community from trying to debug this > > issue further to understand what might be going wrong. > > Yes. > > > Could you offer any guidance about what kind of debugging information I could > collect that would be of use? You can start with picking a single file that demonstrates the problem. Then, ls -li the-file zdb - file's-filesystem file's-inode-number The filesystem can be found out from df output, the inode number is in ls -li output -- if the command prints anything at all. If it does not, then do ls -lid on the file's directory and then zdb - for the directory's inode number. In the output there should be the file name and its number (I think that it's in hex, but not sure). -- 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"
Re: lots of "no such file or directory" errors in zfs filesystem
On 22/02/2021 09:31, Chris Anderson wrote: > None of these files are especially important to me, however I was wondering > if there would be any benefit to the community from trying to debug this > issue further to understand what might be going wrong. Yes. -- 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"
ZFS with 32-bit, non-x86 kernel
Does anyone use ZFS with a 32-bit kernel, that is also not i386 ? If you do, could you please let me know? Along with uname -rmp output. Thank you! -- 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"
ixv + RSS
Has anyone ever tested a kernel with option RSS and an ixv interface? Just looking for some data points. Thanks! -- 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"
Re: Concern: ZFS Mirror issues (12.STABLE and firmware 19 .v. 20)
On 10/04/2019 04:09, Karl Denninger wrote: > Specifically, I *explicitly* OFFLINE the disk in question, which is a > controlled operation and *should* result in a cache flush out of the ZFS > code into the drive before it is OFFLINE'd. > > This should result in the "last written" TXG that the remaining online > members have, and the one in the offline member, being consistent. > > Then I "camcontrol standby" the involved drive, which forces a writeback > cache flush and a spindown; in other words, re-ordered or not, the > on-platter data *should* be consistent with what the system thinks > happened before I yank the physical device. This may not be enough for a specific [RAID] controller and a specific configuration. It should be enough for a dumb HBA. But, for example, mrsas(9) can simply ignore the synchronize cache command (meaning neither the on-board cache is flushed nor the command is propagated to a disk). So, if you use some advanced controller it would make sense to use its own management tool to offline a disk before pulling it. I do not preclude a possibility of an issue in ZFS. But it's not the only possibility either. -- 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"
Re: Concern: ZFS Mirror issues (12.STABLE and firmware 19 .v. 20)
On 09/04/2019 22:01, Karl Denninger wrote: > the resilver JUST COMPLETED with no errors which means the ENTIRE DISK'S > IN USE AREA was examined, compared, and blocks not on the "new member" > or changed copied over. I think that that's not entirely correct. ZFS maintains something called DTL, a dirty-time log, for a missing / offlined / removed device. When the device re-appears and gets resilvered, ZFS walks only those blocks that were born within the TXG range(s) when the device was missing. In any case, I do not have an explanation for what you are seeing. -- 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"
Re: 12.0-RELEASE zfs/vnode deadlock issue
On 04/03/2019 22:35, Nick Rogers wrote:
> v_lock = {lock_object = {lo_name =
> 0x8144af45 "zfs", lo_flags = 117112840, lo_data = 0, lo_witness =
> 0x0}, lk_lock = 18446744073709551605, lk_exslpfail = 0, lk_timo = 51,
> lk_pri = 96}
Hmm, lk_lock looks bogus.
18446744073709551605 == 0xfff5 and it's LK_SHARE |
LK_EXCLUSIVE_WAITERS with 0xfff shared owners.
Perhaps, this is a result of LK_SHARERS_LOCK(-1).
Is your kernel compiled with INVARIANTS and INVARIANT_SUPPORT?
I suspect that the vnode was accessed (unlocked?) through a stale pointer after
it was recycled.
--
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"
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"
Re: 11.2-STABLE kernel wired memory leak
On 12/02/2019 20:17, Eugene Grosbein wrote:
> 13.02.2019 1:14, Eugene Grosbein wrote:
>
>> Use following command to see how much memory is wasted in your case:
>>
>> vmstat -z | awk -F, '{printf "%10s %s\n", $2*$5/1024/1024, $1}' | sort -k1,1
>> -rn | head
>
> Oops, small correction:
>
> vmstat -z | sed 's/:/,/' | awk -F, '{printf "%10s %s\n", $2*$5/1024/1024,
> $1}' | sort -k1,1 -rn | head
I have a much uglier but somewhat more informative "one-liner" for
post-processing vmstat -z output:
vmstat -z | tail +3 | awk -F '[:,] *' 'BEGIN { total=0; cache=0; used=0 } {u =
$2 * $4; c = $2 * $5; t = u + c; cache += c; used += u; total += t; name=$1;
gsub(" ", "_", name); print t, name, u, c} END { print total, "TOTAL", used,
cache } ' | sort -n | perl -a -p -e 'while (($j, $_) = each(@F)) { 1 while
s/^(-?\d+)(\d{3})/$1,$2/; print $_, " "} print "\n"' | column -t
This would be much nicer as a small python script.
Or, even, we could add a sort option for vmstat -z / -m.
--
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"
Re: Kernel panic on 11.2-RELEASE-p7
On 28/12/2018 12:07, Jurij Kovačič via freebsd-stable wrote: > Dear list, > > This morning the server mentioned in my previous e-mail (Freebsd > 11.2-RELEASE-p7 with GENERIC kernel, ZFS root) experienced another kernel > panic: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer= 0x20:0x82299013 > stack pointer= 0x28:0xfe0352893ad0 > frame pointer= 0x28:0xfe0352893b10 > 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= 9 (dbuf_evict_thread) > trap number= 9 > panic: general protection fault > cpuid = 0 > KDB: stack backtrace: > #0 0x80b3d577 at kdb_backtrace+0x67 > #1 0x80af6b17 at vpanic+0x177 > #2 0x80af6993 at panic+0x43 > #3 0x80f77fdf at trap_fatal+0x35f > #4 0x80f7759e at trap+0x5e > #5 0x80f5808c at calltrap+0x8 > #6 0x8229c049 at dbuf_evict_one+0xe9 > #7 0x82297a15 at dbuf_evict_thread+0x1a5 > #8 0x80aba093 at fork_exit+0x83 > #9 0x80f58fae at fork_trampoline+0xe > > I have used the "crashinfo" utility to (again) generate the text file which > is available at this URL: http://www.ocpea.com/dump/core-2.txt > <http://www.ocpea.com/dump/core.txt> This is useless because you do not have debug symbols for the kernel. > Does anyone have any idea how we can go about discovering the cause for > this? We would appreciate any suggestion ... -- 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"
Re: boot hang with certain Phenom II cpu models
On 14/12/2018 21:37, Sascha Klauder wrote: > On Fri, 2018-12-14 11:56 +0200, Andriy Gapon wrote: >> On 13/12/2018 12:56, Sascha Klauder wrote: >>> So far, I tried (unsuccessfully) to disable obvious ACPI sub- >>> systems (cpu, mwait, quirks) and debug settings (acpi.cpu_unordered, >>> acpi.max_threads). Anyone got a hint where to look or debug this >>> further? >> Are you able to identify if you have a hardware or a software hang? >> E.g., are you able to enter ddb? > > Hardware; can't enter ddb and can't toggle caps lock. I could > probably setup remote GDB (serial) but would need some pointer > how to proceed from there. The only idea I have is to boot to ddb (boot_ddb="YES" or boot -d), set a breakpoint in a function from which the last printed line comes[*], continue until the breakpoint is hit and then step from there trying to narrow down a function (or even an instruction) where the hang happens. [*] - seems to be pcie_cfgregopen() -- 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"
Re: boot hang with certain Phenom II cpu models
On 13/12/2018 12:56, Sascha Klauder wrote: > So far, I tried (unsuccessfully) to disable obvious ACPI sub- > systems (cpu, mwait, quirks) and debug settings (acpi.cpu_unordered, > acpi.max_threads). Anyone got a hint where to look or debug this > further? Are you able to identify if you have a hardware or a software hang? E.g., are you able to enter ddb? > kernel boot messages (obtained from 10.4 amd64): > https://lair.griffinsplace.de/~sascha/phenom/dmesg-freeze-FreeBSD10.txt > > boot messages with the previous Athlon II cpu in this system: > https://lair.griffinsplace.de/~sascha/phenom/dmesg-FreeBSD-AthlonII.txt > > boot messages from DFly, OpenBSD and Linux: > https://lair.griffinsplace.de/~sascha/phenom/ -- 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"
Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2
On 22/10/2018 17:32, Eugene Grosbein wrote: > 22.10.2018 21:21, Andriy Gapon wrote: >> This is just a typical foot-shooting (and a shortcoming of the kernel build >> system that allows such foot-shooting to happen). >> I think that there can be other ways in which you can specify inconsistent >> kernel options and/or an incorrect subset of modules in MODULES_OVERRIDE to >> create missing dependencies for critical modules. >> Do we want to issue an errata for each possible misconfiguration? > > OTOH, we have option krpc in sys/conf/options but it is not mentioned > elsewhere: > not in the Handbook nor in the sys/conf/NOTES or GENERIC. Not a bit of our > documentation mentions > that ZFS requires KRPC for last 10 years. > > One can call it foot-shooting if it is against documentation but that's not > the case. I certainly agree that there is a lack of documentation. Still, this is a foot-shooting. Anyway, my point was about a need to create an erratum for this kind of issue. A documentation update would be much more appropriate. -- 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"
Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2
On 22/10/2018 17:15, Glen Barber wrote: > On Mon, Oct 22, 2018 at 09:09:14PM +0700, Eugene Grosbein wrote: >> 22.10.2018 21:03, Glen Barber wrote: >> >> t's strange that this is a 10.x vs 11.x issue. >>>>> I see that zfs has the krpc dependency since r193128. >>>>> And the call to xdrmem_create is there since r168404. >>>> >>>> You are right. I was mis-informed and have not verified enough a report >>>> from local user. >>>> >>>> Glen, maybe that errata record should be deleted. The problem is real but >>>> it is long-standing >>>> and present in 10.x too. >>>> >>> >>> Could you elaborate more on the failure case you originally reported >>> first? If the problem is real, my feeling is that the errata entry >>> should stay, just worded differently to reflect the failure case here. >> >> zfs.ko depends on krpc.ko. The KRPC code in compiled in GENERIC kernel as >> dependency >> of NFS client/server code. The problem arises if all of these are true: >> >> 1) a system uses custom kernel with NFS options removed; >> 2) there is no krpc.ko available due to MODULES_OVERRIDE excluding it; >> 3) the system boots off ZFS pool. >> >> In such case, loader cannot resolve dependency and fails to load zfs.ko >> and kernel fails to mount root breaking boot sequence. >> >> > > So, if I understand correctly (and please correct me if I am wrong), the > majority of the text in the errata note is correct, however needs to be > tweaked to remove "upgrading from 10.x...". Is this generally correct? This is just a typical foot-shooting (and a shortcoming of the kernel build system that allows such foot-shooting to happen). I think that there can be other ways in which you can specify inconsistent kernel options and/or an incorrect subset of modules in MODULES_OVERRIDE to create missing dependencies for critical modules. Do we want to issue an errata for each possible misconfiguration? -- 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"
Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2
On 19/10/2018 12:24, Eugene Grosbein wrote: > On 19.10.2018 13:28, Andriy Gapon wrote: > >>> It was brought to my attention that 10.x did not require availability >>> of krpc for ZFS-on-root system to be bootable but 11.x does. >>> >>> That is, major upgrade of 10.x ZFS-on-root system to 11.x >>> results in non-bootable broken system if it uses custom kernel without NFS >>> bits >>> that automatically come with krpc, and the system was built with >>> MODULES_OVERRIDE="zfs opensolaris" >>> and no krpc mentioned. >> >> Could you please also describe specifics of the problem? >> It's kidn of strange that root-on-zfs requires krpc. > > https://svnweb.freebsd.org/base/stable/11/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c?revision=339111=markup#l7146 > > This code uses some xdr(3) functions to parse zpool.cache > and kernel-side implementation of xdr(3) is contained in krpc.ko > > Out of curiosity, I've commented out mentioned MODULE_DEPEND(zfsctrl, krpc, > 1, 1, 1), > rebuilt zfs.ko and tried to kldload it using UFS-only system having no NFS > code in the kernel > and it failed with a note in dmesg: > > link_elf: symbol xdrmem_create undefined It's strange that this is a 10.x vs 11.x issue. I see that zfs has the krpc dependency since r193128. And the call to xdrmem_create is there since r168404. -- 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"
Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2
On 18/10/2018 20:14, Eugene Grosbein wrote: > Hi! > > It was brought to my attention that 10.x did not require availability > of krpc for ZFS-on-root system to be bootable but 11.x does. > > That is, major upgrade of 10.x ZFS-on-root system to 11.x > results in non-bootable broken system if it uses custom kernel without NFS > bits > that automatically come with krpc, and the system was built with > MODULES_OVERRIDE="zfs opensolaris" > and no krpc mentioned. Could you please also describe specifics of the problem? It's kidn of strange that root-on-zfs requires krpc. > We could have mentioned that requrement in Release Notes but we had not. > > Should we issue an Errata Note? -- 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"
Re: All the memory eaten away by ZFS 'solaris' malloc - on 11.1-R amd64
On 07/08/2018 15:58, Mark Martinec wrote: > Collected, here it is: > > https://www.ijs.si/usr/mark/tmp/dtrace-cmd.out.bz2 I see one memory leak, not sure if it's the only one. It looks like vdev_geom_read_config() leaks all parsed vdev nvlist-s but the last. The problems seems to come from r316760. Before that commit the function would return upon finding the first valid config, but now it keeps iterating. The memory leak should not be a problem when vdev-s are probed sufficiently rarely, but it appears that with an unhealthy pool the probing can happen much more frequently (e.g., every time pools are listed). -- 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"
Re: Continuous crashing ZFS server
On 11/06/2018 13:26, Willem Jan Withagen wrote: > On 11/06/2018 12:13, Andriy Gapon wrote: >> On 08/06/2018 13:02, Willem Jan Withagen wrote: >>> My file server is crashing about every 15 minutes at the moment. >>> The panic looks like: >>> >>> Jun 8 11:48:43 zfs kernel: panic: Solaris(panic): zfs: allocating >>> allocated segment(offset=1291670400 size=24576) >>> Jun 8 11:48:43 zfs kernel: >>> Jun 8 11:48:43 zfs kernel: cpuid = 1 >>> Jun 8 11:48:43 zfs kernel: KDB: stack backtrace: >>> Jun 8 11:48:43 zfs kernel: #0 0x80aada57 at kdb_backtrace+0x67 >>> Jun 8 11:48:43 zfs kernel: #1 0x80a6bb36 at vpanic+0x186 >>> Jun 8 11:48:43 zfs kernel: #2 0x80a6b9a3 at panic+0x43 >>> Jun 8 11:48:43 zfs kernel: #3 0x82488192 at vcmn_err+0xc2 >>> Jun 8 11:48:43 zfs kernel: #4 0x821f73ba at zfs_panic_recover+0x5a >>> Jun 8 11:48:43 zfs kernel: #5 0x821dff8f at range_tree_add+0x20f >>> Jun 8 11:48:43 zfs kernel: #6 0x821deb06 at metaslab_free_dva+0x276 >>> Jun 8 11:48:43 zfs kernel: #7 0x821debc1 at metaslab_free+0x91 >>> Jun 8 11:48:43 zfs kernel: #8 0x896a at zio_dva_free+0x1a >>> Jun 8 11:48:43 zfs kernel: #9 0x8221f6cc at zio_execute+0xac >>> Jun 8 11:48:43 zfs kernel: #10 0x80abe827 at >>> taskqueue_run_locked+0x127 >>> Jun 8 11:48:43 zfs kernel: #11 0x80abf9c8 at >>> taskqueue_thread_loop+0xc8 >>> Jun 8 11:48:43 zfs kernel: #12 0x80a2f7d5 at fork_exit+0x85 >>> Jun 8 11:48:43 zfs kernel: #13 0x80ec4abe at fork_trampoline+0xe >>> Jun 8 11:48:43 zfs kernel: Uptime: 9m7s >>> >>> Maybe a known bug? >>> Is there anything I can do about this? >>> Any debugging needed? >> >> Sorry to inform you but your on-disk data got corrupted. >> The most straightforward thing you can do is try to save data from the pool >> in >> readonly mode. > > Hi Andriy, > > Auch, that is a first in 12 years of using ZFS. "Fortunately" it was of a test > ZVOL->iSCSI->Win10 disk on which I spool my CAMs. > > Removing the ZVOL actually fixed the rebooting, but now the question is: > Is the remainder of the zpools on the same disks in danger? You can try to check with zdb -b on an idle (better exported) pool. And zpool scrub. -- 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"
Re: Continuous crashing ZFS server
On 08/06/2018 13:02, Willem Jan Withagen wrote: > My file server is crashing about every 15 minutes at the moment. > The panic looks like: > > Jun 8 11:48:43 zfs kernel: panic: Solaris(panic): zfs: allocating > allocated segment(offset=1291670400 size=24576) > Jun 8 11:48:43 zfs kernel: > Jun 8 11:48:43 zfs kernel: cpuid = 1 > Jun 8 11:48:43 zfs kernel: KDB: stack backtrace: > Jun 8 11:48:43 zfs kernel: #0 0x80aada57 at kdb_backtrace+0x67 > Jun 8 11:48:43 zfs kernel: #1 0x80a6bb36 at vpanic+0x186 > Jun 8 11:48:43 zfs kernel: #2 0x80a6b9a3 at panic+0x43 > Jun 8 11:48:43 zfs kernel: #3 0x82488192 at vcmn_err+0xc2 > Jun 8 11:48:43 zfs kernel: #4 0x821f73ba at zfs_panic_recover+0x5a > Jun 8 11:48:43 zfs kernel: #5 0x821dff8f at range_tree_add+0x20f > Jun 8 11:48:43 zfs kernel: #6 0x821deb06 at metaslab_free_dva+0x276 > Jun 8 11:48:43 zfs kernel: #7 0x821debc1 at metaslab_free+0x91 > Jun 8 11:48:43 zfs kernel: #8 0x896a at zio_dva_free+0x1a > Jun 8 11:48:43 zfs kernel: #9 0x8221f6cc at zio_execute+0xac > Jun 8 11:48:43 zfs kernel: #10 0x80abe827 at > taskqueue_run_locked+0x127 > Jun 8 11:48:43 zfs kernel: #11 0x80abf9c8 at > taskqueue_thread_loop+0xc8 > Jun 8 11:48:43 zfs kernel: #12 0x80a2f7d5 at fork_exit+0x85 > Jun 8 11:48:43 zfs kernel: #13 0x80ec4abe at fork_trampoline+0xe > Jun 8 11:48:43 zfs kernel: Uptime: 9m7s > > Maybe a known bug? > Is there anything I can do about this? > Any debugging needed? Sorry to inform you but your on-disk data got corrupted. The most straightforward thing you can do is try to save data from the pool in readonly mode. -- 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"
uchcom update
Yesterday I committed some changes to uchcom (so far, only in CURRENT). Commits are r333997 - r334002. If you have a CH340/341 based USB<->RS232 adapter and it works for you, could you please test that it still does? If you tried your adapter in the past and it did not work, there is a chance it might start working now. Could you please test that as well? Thanks! -- 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"
Re: clear old pools remains from active vdevs
On 26/04/2018 18:14, Alan Somers wrote: > On Thu, Apr 26, 2018 at 8:37 AM, Eugene Grosbein <eu...@grosbein.net > <mailto:eu...@grosbein.net>> wrote: > > 26.04.2018 14:50, Andriy Gapon wrote: > > > You can try to use zdb -l to find the stale labels. > > And then zpool labelclear to clear them. > > Our "zpool labelclear" implementation destroys everything (literally). > Have you really tried it? > > > "zpool labelclear" won't help in this case, because you have literally no > devices with active labels. The problem is that the pool is still in your > /boot/zfs/zpool.cache file. I think that plain "zpool destroy esx" will work > in > this case. In the original message Eugene (Zheganin) mentioned that those phantom pools confused the boot chain. I do not think that anything in zpool.cache can do that. -- 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"
Re: clear old pools remains from active vdevs
On 26/04/2018 17:37, Eugene Grosbein wrote: > 26.04.2018 14:50, Andriy Gapon wrote: > >> You can try to use zdb -l to find the stale labels. >> And then zpool labelclear to clear them. > > Our "zpool labelclear" implementation destroys everything (literally). > Have you really tried it? > I have never needed it, so I have never used it. -- 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"
Re: clear old pools remains from active vdevs
On 26/04/2018 10:28, Eugene M. Zheganin wrote: > Hello, > > > I have some active vdev disk members that used to be in pool that clearly have > not beed destroyed properly, so I'm seeing in a "zpool import" output > something > like > > > # zpool import > pool: zroot > id: 14767697319309030904 > state: UNAVAIL > status: The pool was last accessed by another system. > action: The pool cannot be imported due to damaged devices or data. > see: http://illumos.org/msg/ZFS-8000-EY > config: > > zroot UNAVAIL insufficient replicas > mirror-0 UNAVAIL insufficient replicas > 5291726022575795110 UNAVAIL cannot open > 2933754417879630350 UNAVAIL cannot open > > pool: esx > id: 8314148521324214892 > state: UNAVAIL > status: The pool was last accessed by another system. > action: The pool cannot be imported due to damaged devices or data. > see: http://illumos.org/msg/ZFS-8000-EY > config: > > esx UNAVAIL insufficient replicas > mirror-0 UNAVAIL insufficient replicas > 10170732803757341731 UNAVAIL cannot open > 9207269511643803468 UNAVAIL cannot open > > > is there any _safe_ way to get rid of this ? I'm asking because a gptzfsboot > loader in recent -STABLE stumbles upon this and refuses to boot the system > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227772). The workaround is > to > use the 11.1 loader, but I'm afraid this behavior will now be the intended > one. You can try to use zdb -l to find the stale labels. And then zpool labelclear to clear them. -- 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"
Re: kern.sched.quantum: Creepy, sadistic scheduler
On 04/04/2018 03:52, Peter wrote: > Lets run an I/O-active task, e.g, postgres VACUUM that would > continuousely read from big files (while doing compute as well [1]): Not everyone has a postgres server and a suitable database. Could you please devise a test scenario that demonstrates the problem and that anyone could run? -- 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"
Re: GEOM strange error
On 13/03/2018 13:52, Eugene Grosbein wrote: > On 13.03.2018 17:39, Andriy Gapon wrote: >> On 13/03/2018 11:37, Eugene Grosbein wrote: >>> Hi! >>> >>> Let's create a stripe and GPT over it using test files as backing store: >>> >>> truncate -s 1G d0 >>> truncate -s 1G d1 >>> mdconfig -af d0 # gives md0 >>> mdconfig -af d1 # gives md1 >>> >>> gpart create -s GPT md0 >>> gpart create -s GPT md1 >>> gpart destroy -F md1 >>> gpart destroy -F md0# no errors still >>> >>> gstripe label -s $((128*1024)) st0 md0 md1 >>> gpart create -s GPT /dev/stripe/st0 >>> dmesg -a >>> >>> GEOM_STRIPE: Device st0 created (id=4000112224). >>> GEOM_STRIPE: Disk md0 attached to st0. >>> GEOM_STRIPE: Disk md1 attached to st0. >>> GEOM_STRIPE: Device stripe/st0 activated. >>> GEOM: md0: corrupt or invalid GPT detected. >>> GEOM: md0: GPT rejected -- may not be recoverable. >>> >>> Why does it emit such md0-related error? >> >> When GPT is placed on st0 it's opened for writing and, thus, md0 and md1 are >> open for writing too. Afterwards, the write access count is cleared from >> three >> of them and that triggers re-tasting. I guess that g_part code tries to >> taste >> md0 and md1 and sees the GPT label at the start of md0 and the label is >> correctly rejected because it's inconsistent with md0's parameters. > > Shouldn't gstripe grab its components for exclusive access? > So that GEOM does not even try to treat md[01] as targets for re-tasting. I don't know what it should do, but I see that it doesn't do it in the "idle" state. However, when the stripe itself is opened / accessed, then it does add the exclusive bit to requested access counts. See g_stripe_access(). I think that what you expected makes more sense for me than what the code actually does. -- 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"
Re: GEOM strange error
On 13/03/2018 11:37, Eugene Grosbein wrote: > Hi! > > Let's create a stripe and GPT over it using test files as backing store: > > truncate -s 1G d0 > truncate -s 1G d1 > mdconfig -af d0 # gives md0 > mdconfig -af d1 # gives md1 > > gpart create -s GPT md0 > gpart create -s GPT md1 > gpart destroy -F md1 > gpart destroy -F md0 # no errors still > > gstripe label -s $((128*1024)) st0 md0 md1 > gpart create -s GPT /dev/stripe/st0 > dmesg -a > > GEOM_STRIPE: Device st0 created (id=4000112224). > GEOM_STRIPE: Disk md0 attached to st0. > GEOM_STRIPE: Disk md1 attached to st0. > GEOM_STRIPE: Device stripe/st0 activated. > GEOM: md0: corrupt or invalid GPT detected. > GEOM: md0: GPT rejected -- may not be recoverable. > > Why does it emit such md0-related error? When GPT is placed on st0 it's opened for writing and, thus, md0 and md1 are open for writing too. Afterwards, the write access count is cleared from three of them and that triggers re-tasting. I guess that g_part code tries to taste md0 and md1 and sees the GPT label at the start of md0 and the label is correctly rejected because it's inconsistent with md0's parameters. -- 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"
Re: Ryzen issues on FreeBSD ?
On 23/01/2018 19:15, Mike Tancsa wrote: > On 1/22/2018 5:13 PM, Don Lewis wrote: >> On 22 Jan, Mike Tancsa wrote: >>> On 1/22/2018 1:41 PM, Peter Moody wrote: >>>> fwiw, I upgraded to 11-STABLE (11.1-STABLE #6 r328223), applied the >>>> hw.lower_amd64_sharedpage setting to my loader.conf and got a crash >>>> last night following the familiar high load -> idle. this was with SMT >>>> re-enabled. no crashdump, so it was the hard crash that I've been >>>> getting. >>> >>> hw.lower_amd64_sharedpage=1 is the default on AMD boxes no ? I didnt >>> need to set mine to 1 >>> >>>> >>>> shrug, I'm at a loss here. >>> >>> I am trying an RMA with AMD. >> >> Something else that you might want to try is 12.0-CURRENT. There might >> be some changes in HEAD that need to be merged back to 11.1-STABLE. > > > Temp works as expected now. However, a (similar?) hang building Samba47. > > ctrl+T shows If that works, then maybe you can get procstat -kk -a or a crash dump. Maybe this is not a hardware problem at all (or maybe it is). > load: 1.98 cmd: python2.7 53438 [usem] 54.70r 14.98u 6.04s 0% 230992k > make: Working in: /usr/ports/net/samba47 > load: 0.34 cmd: python2.7 53438 [usem] 168.48r 14.98u 6.04s 0% 230992k > make: Working in: /usr/ports/net/samba47 > load: 0.31 cmd: python2.7 53438 [usem] 174.12r 14.98u 6.04s 0% 230992k > make: Working in: /usr/ports/net/samba47 -- 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"
Re: idprio(1) broken
On 26/12/2017 11:18, Eugene Grosbein wrote: > On 26.12.2017 16:10, Eugene Grosbein wrote: > >> Is idprio(1) broken in stable/11? >> >> As root, start one bzip2 instance with idprio and one additional bzip2 >> intance per CPU core: >> >> # idprio 5 bzip2 -9 /dev/null & >> # n=$(sysctl -n kern.smp.cpus) >> # i=1; while [ $i -le $n ]; do bzip2 -9 /dev/null & i=$(($i+1)); >> done >> # top >> >> For dual core system, I see that idprio'd bzip2 takes all cycles of first >> core >> and two "normal" bzip2's share cycles of second core each taking ~50% of CPU >> time. >> >> It is expected that idprio'd bzip2 get no CPU time at all and each of >> "normal" bzip2's >> get ~100% of single CPU core for such setup. > > This works as expected for stable/10. Seems to work as expected on head as well. Tested on a 6-core physical system and a 2-core bhyve VM. # ps axwwl | fgrep bzip2 0 943 935 0 129 5 10564 2196 -RN1 0:00.00 idprio 5 bzip2 -9 0 945 935 0 108 5 18332 9676 -RN1 1:16.15 bzip2 -9 0 946 935 0 108 5 18332 9676 -RN1 1:16.34 bzip2 -9 idprio isn't even able to exec bzip2. # ps axwwl | fgrep bzip2 0 28986 86816 0 129 5 183482324 -RN 17 0:00.02 bzip2 -9 0 28988 86816 0 106 5 183489680 -RN 17 1:27.25 bzip2 -9 0 28989 86816 0 106 5 183489680 -RN 17 1:27.86 bzip2 -9 0 28990 86816 0 108 5 183489680 -RN 17 1:35.50 bzip2 -9 0 28991 86816 0 106 5 183489680 -RN 17 1:27.00 bzip2 -9 0 28992 86816 0 106 5 183489680 -RN 17 1:25.83 bzip2 -9 0 28993 86816 0 106 5 183489680 -RN 17 1:26.76 bzip2 -9 -- 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"
Re: panic: Solaris(panic): blkptr invalid CHECKSUM1
On 03/10/2017 17:19, Harry Schmalzbauer wrote: > Have tried several different txg IDs, but the latest 5 or so lead to the > panic and some other random picked all claim missing devices... > Doh, if I only knew about -T some days ago, when I had all 4 devices > available. I don't think that the error is really about the missing devices. Most likely the real problem is that you are going too far back in history where the data required to import the pool is not present. It's just that there is no special error code to report that condition distinctly, so it gets interpreted as a missing device condition. -F/-X/-T is not guaranteed to work as the old (freed, overwritten) data is not kept indefinitely. -- 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"
Re: panic: Solaris(panic): blkptr invalid CHECKSUM1
On 03/10/2017 11:43, Harald Schmalzbauer wrote: ... > action: The pool can be imported despite missing or damaged devices. The > fault tolerance of the pool may be compromised if imported. ... > Is it impossible to import degraded pools in general, or only together> with > "-X -T"? It should be possible to import degraded pools... Perhaps the pool originally had more devices? Like log devices. Or maybe there is some issue with the txg you picked. By the way, I think that you didn't have to provide -T option for -F or -X. It's either -F or -X or -T , the first two try to figure out txg automatically. But I could be wrong. -- 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"
Re: my build time impact of clang 5.0
On 02/10/2017 21:34, Dan Mack wrote: > > Another significant change in build times this week - not complaining, > just my observations on build times; same server doing buildworld during > the various phases of compiler changes over the last year or so FWIW: > > |--+--+---+--+---| > | Ver (svn-id) | World (mins) | Kernel (mins) | Relative | Comment | > |--+--+---+--+---| > | 292733 | 90 |16 | 0.5 | | > | 299948 | 89 |16 | 0.5 | | > | 322724 | 174 |21 | 1.0 | clang 4.x | > | 323310 | 175 |21 | 1.0 | clang 4.x | > | 323984 | 175 |21 | 1.0 | clang 4.x | > | 324130 | 285 |21 | 1.6 | clang 5.x | > | 324204 | 280 |21 | 1.6 | clang 5.x | > |--+--+---+--+---| It shocked me to a realize that I can build several platforms that do not have clang support yet (like powerpc) one after another in a fraction of time required to build just amd64. -- 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"
Re: panic: Solaris(panic): blkptr invalid CHECKSUM1
On 01/10/2017 00:38, Harry Schmalzbauer wrote: > Now my striped mirror has all 4 devices healthy available, but all > datasets seem to be lost. > No problem for 450G (99,9_%), but there's a 80M dataset which I'm really > missing :-( If it's not too late now, you may try to experiment with an "unwind" / "extreme unwind" import using -F -n / -X -n. Or manually specifying a txg number for import (in read-only mode). -- 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"
Re: syslogd regression not fixed in stable branches
On 02/06/2017 15:03, Eugene Grosbein wrote: > Hi! > > 11.1 code freeze is already in effect but a regression in syslogd reported in > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215335 and fixed in HEAD > still not MFC'd ti stable branches and PR Assignee seems to be unresponding. > > Is it possible to get that simple MFC happen so 11.1-RELEASE be unaffected? Yes, sure. You can do it. https://wiki.freebsd.org/Releng/ChangeRequestGuidelines -- 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"
Re: Opteron 6100-series "Magny-Cours"
On 03/25/2017 23:26, Jack L. wrote: > I have a few still sitting in a corner with FreeBSD 7 or 8 on them. Someday i > might put them back on with FreeBSD but not anytime soon Apologies for not qualifying my question. I would like to obtain some information from such a system and possibly to ask to test a patch. Looks like you won't be able to help with that. At least, until that some day :-). >> On Mar 25, 2017, at 11:02 AM, Andriy Gapon <a...@freebsd.org> wrote: >> >> >> Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with >> FreeBSD? -- 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"
Opteron 6100-series "Magny-Cours"
Does anyone [still] use Opteron 6100-series / "Magny-Cours" processors with FreeBSD? -- 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"
Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11 due to lack of waiting for da0
On 16/03/2017 13:18, Pete French wrote: > >> So, the kernel attempted to mount the root even before vmbus was attached >> and, >> thus, before storvsc appeared and informed the kernel that it might be >> holding >> the root. >> How ZFS was supposed to know that vmbus is ever going to appear? >> To me this sounds more like a problem with the Hyper-V drivers. > > I am currently running with the patch which waits for a number fo seconds and > retries the mount, and that appears t fix it. However I dont really like > rnning > a patched OS. How would I set about reporting this to Microsoft and getting it > fixed, or getting the timeoutpatch commited ? Preferably both, as the timeout > patch is generally a useful thing to have working for ZFS I think. I don't like the delay and retry approach at all. Imagine that you told the kernel that you want to mount your root from a ZFS pool which is on a USB driver which you have already thrown out. Should the kernel just keep waiting for that pool to appear? Microsoft provides support for FreeBSD Hyper-V drivers. Please try to discuss this problem on virtualization@ or with sephe@ directly. -- 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"
Re: moutnroot failing on zpools in Azure after upgrade from 10 to 11 due to lack of waiting for da0
On 13/03/2017 21:07, Edward Tomasz Napierała wrote: > Are you sure the above transcript is right? There are three reasons > I'm asking. First, you'll see the "Root mount waiting" message, > which means the root mount code is, well, waiting for storvsc, exactly > as expected. Second - there is no "Trying to mount root". But most > of all - for some reason the "Mounting failed" is shown _before_ the > "Root mount waiting", and I have no idea how this could ever happen. Edward, your observation is not completely correct. https://www.twisted.org.uk/~pete/914893a3-249e-4a91-851c-f467fc185eec.txt We have: Trying to mount root from zfs:rpool/ROOT/default []... <=== vmbus0: version 3.0 ... storvsc0: on vmbus0 Solaris: NOTICE: Cannot find the pool label for 'rpool' Mounting from zfs:rpool/ROOT/default failed with error 5. <=== Root mount waiting for: storvsc <=== ... So, the kernel attempted to mount the root even before vmbus was attached and, thus, before storvsc appeared and informed the kernel that it might be holding the root. How ZFS was supposed to know that vmbus is ever going to appear? To me this sounds more like a problem with the Hyper-V drivers. -- 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"
CFT: aacraid users
If you currently use aacraid(4) driver and can afford to run a test, could you please test if you get any regressions after applying the following patch? https://reviews.freebsd.org/D9900.diff Thank you! -- 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"
Re: cyapa(4) and isl(4) no longer working on Acer C720
On 25/02/2017 16:46, Andriy Gapon wrote:
> On 25/02/2017 15:10, Wolfgang Zenker wrote:
>> Hi,
>>
>> I'm using FreeBSD 11 on a chromebook Acer C720. Because I normally
>> use a mouse I didn't catch the exact time when cyapa and isl stopped
>> working, but my guess is it was when chromebook_framework was introduced
>> and cyapa and isl were moved to using iic.
>>
>> A manual page chromebook_platform(4) does not exist. Maybe the Acer is
>> sufficiently different from other chromebooks that chromebook_platform
>> does not work here. In that case I'm supposed to set device hints for
>> the isl and cyapa drivers where to find their iic resources, according
>> to
>> https://github.com/freebsd/freebsd-base-graphics/commit/e2eab8e254154d36ebd6fde573f86e6472b75572
>> Unfortunately I have no idea where to find the information that would
>> be needed for this.
> The manual page actually exists... but only in the source code :-(
> share/man/man4/chromebook_platform.4
> Mea culpa.
>
> You can look through this Linux source file to check for information that's
> relevant to your laptop:
> http://lxr.free-electrons.com/source/drivers/platform/chrome/chromeos_laptop.c
In fact, could you please try this trivial patch?
Index: sys/dev/chromebook_platform/chromebook_platform.c
===
--- sys/dev/chromebook_platform/chromebook_platform.c (revision 314268)
+++ sys/dev/chromebook_platform/chromebook_platform.c (working copy)
@@ -69,7 +69,7 @@
* See
http://lxr.free-electrons.com/source/drivers/platform/chrome/chromeos_laptop.c
*/
controller = device_get_parent(bus);
- if (strcmp(device_get_name(controller), "ig4iic") != 0)
+ if (strcmp(device_get_name(controller), "ig4iic_pci") != 0)
return;
for (i = 0; i < nitems(slaves); i++) {
Seems like I overlooked this when reviewing
https://svnweb.freebsd.org/base?view=revision=310621
--
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"
Re: cyapa(4) and isl(4) no longer working on Acer C720
removable, self powered > Root mount waiting for: usbus1 usbus0 > ugen0.2: at usbus0 > ugen1.2: at usbus1 > uhub2 on uhub1 > uhub2: on > usbus1 > ugen0.3: at usbus0 > uhub2: 8 ports with 8 removable, self powered > info: [drm] Initialized drm 1.1.0 20060810 > iic0: on iicbus0 > iic1: on iicbus1 > drmn0: on vgapci0 > info: [drm] Memory usable by graphics device = 2048M > intel_iicbb0 on drmn0 > iicbus2: error: [drm:pid147:i915_write32] *ERROR* Unknown > unclaimed register before writing to c5100 > on iicbb0 addr 0xff > iic2: on iicbus2 > iicbus3: on intel_gmbus0 > iic3: on iicbus3 > intel_iicbb1 on drmn0 > iicbus4: on iicbb1 addr 0x0 > iic4: on iicbus4 > iicbus5: on intel_gmbus1 > iic5: on iicbus5 > intel_iicbb2 on drmn0 > iicbus6: on iicbb2 addr 0x0 > iic6: on iicbus6 > iicbus7: on intel_gmbus2 > iic7: on iicbus7 > intel_iicbb3 on drmn0 > iicbus8: on iicbb3 addr 0x0 > iic8: on iicbus8 > iicbus9: on intel_gmbus3 > iic9: on iicbus9 > intel_iicbb4 on drmn0 > iicbus10: on iicbb4 addr 0x0 > iic10: on iicbus10 > iicbus11: on intel_gmbus4 > iic11: on iicbus11 > intel_iicbb5 on drmn0 > iicbus12: on iicbb5 addr 0x0 > iic12: on iicbus12 > iicbus13: on intel_gmbus5 > iic13: on iicbus13 > info: [drm] MSI enabled 1 message(s) > info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > info: [drm] Driver supports precise vblank timestamp query. > drm_iic_dp_aux0 on drmn0 > drm_iic_dp_aux1 on drmn0 > drmn0: taking over the fictitious range 0xd000-0xe000 > info: [drm] Connector eDP-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.eDP-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector HDMI-A-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.HDMI-A-1 > info: [drm] - kern.vt.fb.default_mode > info: [drm] Connector DP-1: get mode from tunables: > info: [drm] - kern.vt.fb.modes.DP-1 > info: [drm] - kern.vt.fb.default_mode > fbd0 on drmn0 > VT: Replacing driver "vga" with new "fb". > info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 > wlan0: Ethernet address: 9c:d2:1e:9b:e6:41 > info: [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off > wlan0: link state changed to UP > - > > Output of kldstat: > - > Id Refs AddressSize Name > 1 55 0x8020 1f5ab88 kernel > 21 0x8215c000 313dd8 zfs.ko > 32 0x8247 cb08 opensolaris.ko > 41 0x8247d000 4c20 coretemp.ko > 51 0x82482000 1e20 chromebook_platform.ko > 61 0x82484000 8848 ig4.ko > 79 0x8248d000 6fd0 iicbus.ko > 81 0x82494000 96b8 cyapa.ko > 91 0x8249e000 3180 isl.ko > 101 0x82621000 96a0ai915kms.ko > 111 0x826b8000 5446fdrm2.ko > 121 0x8270d000 1c62 iic.ko > 131 0x8270f000 1e6e iicbb.ko > 141 0x82711000 4f48 ng_ubt.ko > 152 0x82716000 c1bf netgraph.ko > 161 0x82723000 a62d ng_hci.ko > 171 0x8272e000 1087 ng_bluetooth.ko > - -- 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"
Re: Is it known problem, that zfs.ko could not be built with system compiler (clang 3.9.1) without optimization?
On 22/02/2017 22:47, Lev Serebryakov wrote: > Hello Freebsd-stable, > >Now if you build zfs.ko with -O0 it panics on boot. I have seen a problem that matches your description, but not necessarily the same one: https://lists.freebsd.org/pipermail/freebsd-hackers/2016-July/049768.html >If you use default optimization level, a lot of fbt DTreace probes are > missing. You can try several different (orthogonal, even) approaches: - compile ZFS into the kernel - use higher optimization level, but add -fno-optimize-sibling-calls to CLFAGS - pkg install amd64-xtoolchain-gcc and then use CROSS_TOOLCHAIN=amd64-gcc command line argument for buildkernel -- 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"
Re: major code change for .zfs
On 23/08/2016 11:43, Andriy Gapon wrote: > > Please review and test a change to .zfs code that is intended to make the code > aligned with FreeBSD VFS and, as such, more stable: > https://reviews.freebsd.org/D7421 > > The change removes two features. > .zfs/shares is gone because it was unused on FreeBSD anyway. We can restore > that when we need it. > An ability to take a snapshot by creating a directory under .zfs/snapshot is > removed. I hope that you didn't use it. Please do not start using it now :-) > Again, this feature can be restored with some work. > The reason I removed it is that its companion features of destroying and > renaming snapshots were already missing on FreeBSD, and properly implementing > the feature required some more work. This is a heads-up that I am going to commit the change. If you have objections or concerns please speak up. Thanks! -- 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"
Re: FreeBSD_STABLE_10-i386 - Build #1643 - Still Failing
On 18/01/2017 18:58, jenkins-ad...@freebsd.org wrote: > FreeBSD_STABLE_10-i386 - Build #1643 - Still Failing: > > Build information: > https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/ > Full change log: > https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/changes > Full build log: > https://jenkins.FreeBSD.org/job/FreeBSD_STABLE_10-i386/1643/console > > Change summaries: > > 312386 by pfg: > MFC r311947, r311981: > > rpcgen(1): Avoid unused variable warning on generated code. > > Avoid "unused variable 'i'" warnings in generated .c files by only > emitting the "int i;" for non-opaque arrays. Opaque arrays use > xdr_opaque() rather than iterating over the array. > > Obtained from:OpenBSD (CVS rev 1.28) > > rpcgen(1): Check getrlimit() return for generated code. > > Obtained from:NetBSD (CVS rev 1.27, 1.28) > > 312382 by avg: > MFC r310630: libkvm: support access to vmm guest memory, allow writes to > fwmem and vmm > > Sponsored by: Panzura > > > > The end of the build log: ... > make[5]: make[5]: don't know how to make gzguts.h. Stop > > make[5]: stopped in /usr/src/sys/boot/libstand32 gzguts.h in libstand32? That does not seem to be related to any of the commits listed at the beginning. -- 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"
Re: FreeBSD_STABLE_10-i386 - Build #1547 - Failure
On 14/12/2016 19:04, jenkins-ad...@freebsd.org wrote:
> --- fwohci.o ---
> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
> -DHAVE_KERNEL_OPTION_HEADERS -include
> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -fno-common
> -g -I/usr/obj/usr/src/sys/GENERIC -mno-aes -mno-avx -mno-mmx -mno-sse
> -msoft-float -ffreestanding -fstack-protector -gdwarf-2 -std=iso9899:1999
> -Qunused-arguments -fstack-protector -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 -Wno-error-tautological-compare
> -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function -c
> /usr/src/sys/modules/firewire/firewire/../../../dev/firewire/fwohci.c -o
> fwohci.o
> --- all_subdir_drm2 ---
> --- radeon_ttm.o ---
> ctfconvert -L VERSION -g radeon_ttm.o
> --- all_subdir_firmware ---
> ctfconvert -L VERSION -g subr_firmware.o
> --- all_subdir_firewire ---
> /usr/src/sys/modules/firewire/firewire/../../../dev/firewire/fwohci.c:1878:9:
> error: use of undeclared identifier 'prequpper'
> (prequpper & 0x)) {
Sorry about this, should be fixed by r310081.
--
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"
Re: gdb broken on stable/11 and current?
On 08/12/2016 18:57, Slawa Olhovchenkov wrote: > kgdb7111 don't find .debug under /usr/lib/debug/ > gdb found it. $ gdb7111 bhyve /var/coredumps/bhyve.0.0.core GNU gdb (GDB) 7.11.1 [GDB v7.11.1 for FreeBSD] Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd11.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from bhyve...Reading symbols from /usr/lib/debug//usr/sbin/bhyve.debug...done. Something is wrong in your environment. -- 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"
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 14/11/2016 14:00, Henri Hennebert wrote:
> On 11/14/2016 12:45, Andriy Gapon wrote:
>> Okay. Luckily for us, it seems that 'm' is available in frame 5. It also
>> happens to be the first field of 'struct faultstate'. So, could you please
>> go
>> to frame and print '*m' and '*(struct faultstate *)m' ?
>>
> (kgdb) fr 4
> #4 0x8089d1c1 in vm_page_busy_sleep (m=0xf800df68cd40,
> wmesg= optimized out>) at /usr/src/sys/vm/vm_page.c:753
> 753msleep(m, vm_page_lockptr(m), PVM | PDROP, wmesg, 0);
> (kgdb) print *m
> $1 = {plinks = {q = {tqe_next = 0xf800dc5d85b0, tqe_prev =
> 0xf800debf3bd0}, s = {ss = {sle_next = 0xf800dc5d85b0},
> pv = 0xf800debf3bd0}, memguard = {p = 18446735281313646000, v =
> 18446735281353604048}}, listq = {tqe_next = 0x0,
> tqe_prev = 0xf800dc5d85c0}, object = 0xf800b62e9c60, pindex = 11,
> phys_addr = 3389358080, md = {pv_list = {
> tqh_first = 0x0, tqh_last = 0xf800df68cd78}, pv_gen = 426, pat_mode
> =
> 6}, wire_count = 0, busy_lock = 6, hold_count = 0,
> flags = 0, aflags = 2 '\002', oflags = 0 '\0', queue = 0 '\0', psind = 0
> '\0',
> segind = 3 '\003', order = 13 '\r',
> pool = 0 '\0', act_count = 0 '\0', valid = 0 '\0', dirty = 0 '\0'}
If I interpret this correctly the page is in the 'exclusive busy' state.
Unfortunately, I can't tell much beyond that.
But I am confident that this is the root cause of the lock-up.
> (kgdb) print *(struct faultstate *)m
> $2 = {m = 0xf800dc5d85b0, object = 0xf800debf3bd0, pindex = 0,
> first_m =
> 0xf800dc5d85c0,
> first_object = 0xf800b62e9c60, first_pindex = 11, map = 0xca058000,
> entry
> = 0x0, lookup_still_valid = -546779784,
> vp = 0x601aa}
> (kgdb)
I was wrong on this one as 'm' is actually a pointer, so the above is not
correct. Maybe 'info reg' in frame 5 would give a clue about the value of 'fs'.
I am not sure how to proceed from here.
The only thing I can think of is a lock order reversal between the vnode lock
and the page busying quasi-lock. But examining the code I can not spot it.
Another possibility is a leak of a busy page, but that's hard to debug.
How hard is it to reproduce the problem?
Maybe Konstantin would have some ideas or suggestions.
--
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"
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 14/11/2016 11:35, Henri Hennebert wrote: > > > On 11/14/2016 10:07, Andriy Gapon wrote: >> Hmm, I've just noticed another interesting thread: >> Thread 668 (Thread 101245): >> #0 sched_switch (td=0xf800b642aa00, newtd=0xf8000285f000, >> flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 >> #1 0x80561ae2 in mi_switch (flags=, newtd=0x0) >> at >> /usr/src/sys/kern/kern_synch.c:455 >> #2 0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at >> /usr/src/sys/kern/subr_sleepqueue.c:646 >> #3 0x805614b1 in _sleep (ident=, lock=> optimized out>, priority=, wmesg=0x809c51bc >> "vmpfw", sbt=0, pr=, flags=) at >> /usr/src/sys/kern/kern_synch.c:229 >> #4 0x8089d1c1 in vm_page_busy_sleep (m=0xf800df68cd40, >> wmesg=> optimized out>) at /usr/src/sys/vm/vm_page.c:753 >> #5 0x8089dd4d in vm_page_sleep_if_busy (m=0xf800df68cd40, >> msg=0x809c51bc "vmpfw") at /usr/src/sys/vm/vm_page.c:1086 >> #6 0x80886be9 in vm_fault_hold (map=, >> vaddr=> optimized out>, fault_type=4 '\004', fault_flags=0, m_hold=0x0) at >> /usr/src/sys/vm/vm_fault.c:495 >> #7 0x80885448 in vm_fault (map=0xf80011d66000, vaddr=> optimized out>, fault_type=4 '\004', fault_flags=) at >> /usr/src/sys/vm/vm_fault.c:273 >> #8 0x808d3c49 in trap_pfault (frame=0xfe0101836c00, usermode=1) >> at >> /usr/src/sys/amd64/amd64/trap.c:741 >> #9 0x808d3386 in trap (frame=0xfe0101836c00) at >> /usr/src/sys/amd64/amd64/trap.c:333 >> #10 0x808b7af1 in calltrap () at >> /usr/src/sys/amd64/amd64/exception.S:236 > > This tread is another program from the news system: > 668 Thread 101245 (PID=49124: innfeed) sched_switch (td=0xf800b642aa00, > newtd=0xf8000285f000, flags=) at > /usr/src/sys/kern/sched_ule.c:1973 > >> >> I strongly suspect that this is thread that we were looking for. >> I think that it has the vnode lock in the shared mode while trying to fault >> in a >> page. >> >> Could you please check that by going to frame 6 and printing 'fs' and >> '*fs.vp'? >> It'd be interesting to understand why this thread is waiting here. >> So, please also print '*fs.m' and '*fs.object'. > > No luck :-( > (kgdb) fr 6 > #6 0x80886be9 in vm_fault_hold (map=, > vaddr= optimized out>, fault_type=4 '\004', > fault_flags=0, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:495 > 495vm_page_sleep_if_busy(fs.m, "vmpfw"); > (kgdb) print fs > Cannot access memory at address 0x1fa0 > (kgdb) Okay. Luckily for us, it seems that 'm' is available in frame 5. It also happens to be the first field of 'struct faultstate'. So, could you please go to frame and print '*m' and '*(struct faultstate *)m' ? -- 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"
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 13/11/2016 15:28, Henri Hennebert wrote: > On 11/13/2016 11:06, Andriy Gapon wrote: >> On 12/11/2016 14:40, Henri Hennebert wrote: >>> I attatch it >> >> Thank you! >> So, these two threads are trying to get the lock in the exclusive mode: >> Thread 687 (Thread 101243): >> #0 sched_switch (td=0xf800b642b500, newtd=0xf8000285ea00, >> flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 >> #1 0x80561ae2 in mi_switch (flags=, newtd=0x0) >> at >> /usr/src/sys/kern/kern_synch.c:455 >> #2 0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at >> /usr/src/sys/kern/subr_sleepqueue.c:646 >> #3 0x8052f854 in sleeplk (lk=, flags=> optimized out>, ilk=, wmesg=0x813be535 "zfs", >> pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 >> #4 0x8052f39d in __lockmgr_args (lk=, >> flags=> optimized out>, ilk=, wmesg=, >> pri=, timo=, file=> out>, line=) at /usr/src/sys/kern/kern_lock.c:958 >> #5 0x80616a8c in vop_stdlock (ap=) at >> lockmgr.h:98 >> #6 0x8093784d in VOP_LOCK1_APV (vop=, a=> optimized out>) at vnode_if.c:2087 >> #7 0x8063c5b3 in _vn_lock (vp=, flags=548864, >> file=, line=) at vnode_if.h:859 >> #8 0x8062a5f7 in vget (vp=0xf80049c2c000, flags=548864, >> td=0xf800b642b500) at /usr/src/sys/kern/vfs_subr.c:2523 >> #9 0x806118b9 in cache_lookup (dvp=, vpp=> optimized out>, cnp=, tsp=, >> ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 >> #10 0x806133dc in vfs_cache_lookup (ap=) at >> /usr/src/sys/kern/vfs_cache.c:1081 >> #11 0x80935777 in VOP_LOOKUP_APV (vop=, a=> optimized out>) at vnode_if.c:127 >> #12 0x8061cdf1 in lookup (ndp=) at vnode_if.h:54 >> #13 0x8061c492 in namei (ndp=) at >> /usr/src/sys/kern/vfs_lookup.c:306 >> #14 0x80509395 in kern_execve (td=, args=> optimized out>, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 >> #15 0x80508ccc in sys_execve (td=0xf800b642b500, >> uap=0xfe010182cb80) at /usr/src/sys/kern/kern_exec.c:218 >> #16 0x808d449e in amd64_syscall (td=, traced=0) >> at >> subr_syscall.c:135 >> #17 0x808b7ddb in Xfast_syscall () at >> /usr/src/sys/amd64/amd64/exception.S:396 >> >> Thread 681 (Thread 101147): >> #0 sched_switch (td=0xf80065f4e500, newtd=0xf8000285f000, >> flags=> optimized out>) at /usr/src/sys/kern/sched_ule.c:1973 >> #1 0x80561ae2 in mi_switch (flags=, newtd=0x0) >> at >> /usr/src/sys/kern/kern_synch.c:455 >> #2 0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at >> /usr/src/sys/kern/subr_sleepqueue.c:646 >> #3 0x8052f854 in sleeplk (lk=, flags=> optimized out>, ilk=, wmesg=0x813be535 "zfs", >> pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 >> #4 0x8052f39d in __lockmgr_args (lk=, >> flags=> optimized out>, ilk=, wmesg=, >> pri=, timo=, file=> out>, line=) at /usr/src/sys/kern/kern_lock.c:958 >> #5 0x80616a8c in vop_stdlock (ap=) at >> lockmgr.h:98 >> #6 0x8093784d in VOP_LOCK1_APV (vop=, a=> optimized out>) at vnode_if.c:2087 >> #7 0x8063c5b3 in _vn_lock (vp=, flags=548864, >> file=, line=) at vnode_if.h:859 >> #8 0x8062a5f7 in vget (vp=0xf80049c2c000, flags=548864, >> td=0xf80065f4e500) at /usr/src/sys/kern/vfs_subr.c:2523 >> #9 0x806118b9 in cache_lookup (dvp=, vpp=> optimized out>, cnp=, tsp=, >> ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 >> #10 0x806133dc in vfs_cache_lookup (ap=) at >> /usr/src/sys/kern/vfs_cache.c:1081 >> #11 0x80935777 in VOP_LOOKUP_APV (vop=, a=> optimized out>) at vnode_if.c:127 >> #12 0x8061cdf1 in lookup (ndp=) at vnode_if.h:54 >> #13 0x8061c492 in namei (ndp=) at >> /usr/src/sys/kern/vfs_lookup.c:306 >> #14 0x80509395 in kern_execve (td=, args=> optimized out>, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 >> #15 0x80508ccc in sys_execve (td=0xf80065f4e500, >> uap=0xfe01016b8b80) at /usr/src/sys/kern/kern_exec.c:218 >> #16 0x808d449e in amd64_syscall (td=, traced=0) >> at >> subr_syscall.c:135 >> #17 0x808b7ddb in Xfast_syscall () at >> /usr/src/sys/amd64/amd64/exception.S:396 > > This 2 threads are innd processes. In core.txt.4: > >8 14789 29165 0 24 4 40040 6612 zfs DN- 0:00.00 [innd] >8 29165 1 0 20 0 42496 6888 select Ds- 0:
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 12/11/2016 14:40, Henri Hennebert wrote: > I attatch it Thank you! So, these two threads are trying to get the lock in the exclusive mode: Thread 687 (Thread 101243): #0 sched_switch (td=0xf800b642b500, newtd=0xf8000285ea00, flags=) at /usr/src/sys/kern/sched_ule.c:1973 #1 0x80561ae2 in mi_switch (flags=, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:455 #2 0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:646 #3 0x8052f854 in sleeplk (lk=, flags=, ilk=, wmesg=0x813be535 "zfs", pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 #4 0x8052f39d in __lockmgr_args (lk=, flags=, ilk=, wmesg=, pri=, timo=, file=, line=) at /usr/src/sys/kern/kern_lock.c:958 #5 0x80616a8c in vop_stdlock (ap=) at lockmgr.h:98 #6 0x8093784d in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2087 #7 0x8063c5b3 in _vn_lock (vp=, flags=548864, file=, line=) at vnode_if.h:859 #8 0x8062a5f7 in vget (vp=0xf80049c2c000, flags=548864, td=0xf800b642b500) at /usr/src/sys/kern/vfs_subr.c:2523 #9 0x806118b9 in cache_lookup (dvp=, vpp=, cnp=, tsp=, ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 #10 0x806133dc in vfs_cache_lookup (ap=) at /usr/src/sys/kern/vfs_cache.c:1081 #11 0x80935777 in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:127 #12 0x8061cdf1 in lookup (ndp=) at vnode_if.h:54 #13 0x8061c492 in namei (ndp=) at /usr/src/sys/kern/vfs_lookup.c:306 #14 0x80509395 in kern_execve (td=, args=, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 #15 0x80508ccc in sys_execve (td=0xf800b642b500, uap=0xfe010182cb80) at /usr/src/sys/kern/kern_exec.c:218 #16 0x808d449e in amd64_syscall (td=, traced=0) at subr_syscall.c:135 #17 0x808b7ddb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 Thread 681 (Thread 101147): #0 sched_switch (td=0xf80065f4e500, newtd=0xf8000285f000, flags=) at /usr/src/sys/kern/sched_ule.c:1973 #1 0x80561ae2 in mi_switch (flags=, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:455 #2 0x805ae8da in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:646 #3 0x8052f854 in sleeplk (lk=, flags=, ilk=, wmesg=0x813be535 "zfs", pri=, timo=51) at /usr/src/sys/kern/kern_lock.c:222 #4 0x8052f39d in __lockmgr_args (lk=, flags=, ilk=, wmesg=, pri=, timo=, file=, line=) at /usr/src/sys/kern/kern_lock.c:958 #5 0x80616a8c in vop_stdlock (ap=) at lockmgr.h:98 #6 0x8093784d in VOP_LOCK1_APV (vop=, a=) at vnode_if.c:2087 #7 0x8063c5b3 in _vn_lock (vp=, flags=548864, file=, line=) at vnode_if.h:859 #8 0x8062a5f7 in vget (vp=0xf80049c2c000, flags=548864, td=0xf80065f4e500) at /usr/src/sys/kern/vfs_subr.c:2523 #9 0x806118b9 in cache_lookup (dvp=, vpp=, cnp=, tsp=, ticksp=) at /usr/src/sys/kern/vfs_cache.c:686 #10 0x806133dc in vfs_cache_lookup (ap=) at /usr/src/sys/kern/vfs_cache.c:1081 #11 0x80935777 in VOP_LOOKUP_APV (vop=, a=) at vnode_if.c:127 #12 0x8061cdf1 in lookup (ndp=) at vnode_if.h:54 #13 0x8061c492 in namei (ndp=) at /usr/src/sys/kern/vfs_lookup.c:306 #14 0x80509395 in kern_execve (td=, args=, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:443 #15 0x80508ccc in sys_execve (td=0xf80065f4e500, uap=0xfe01016b8b80) at /usr/src/sys/kern/kern_exec.c:218 #16 0x808d449e in amd64_syscall (td=, traced=0) at subr_syscall.c:135 #17 0x808b7ddb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 And the original stuck thread wants to get the lock in the shared mode. And there should be another thread that already holds the lock in the shared mode. But I am not able to identify it. I wonder if the original thread could be trying to get the lock recursively... It would be interesting to get more details from thread 101112. You can switch to it using tid command, you can use 'fr' to select frames, 'info local' and 'info args' to see what variables are available (not optimized out) and the you can print any that look interesting. It would be nice to get a file path and a directory vnode where the lookup is called. Thank you. -- 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"
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 11/11/2016 16:50, Henri Hennebert wrote: > > > On 11/11/2016 12:24, Andriy Gapon wrote: >> >> At this stage I would try to get a system crash dump for post-mortem >> analysis. >> There are a few way to do that. You can enter ddb and then run 'dump' and >> 'reset' commands. Or you can just do `sysctl debug.kdb.panic=1`. >> In either case, please double-check that your system has a dump device >> configured. >> > It take some time to upload the dump... > > You can find it at > > http://tignes.restart.be/Xfer/ Could you please open the dump in kgdb and execute the following commands? set logging on set logging redirect on set pagination off thread apply all bt quit After that you should get gdb.txt file in the current directory. I would like to see it. Thank you. -- 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"
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 10/11/2016 21:41, Henri Hennebert wrote:
> On 11/10/2016 19:40, Andriy Gapon wrote:
>> On 10/11/2016 19:55, Henri Hennebert wrote:
>>>
>>>
>>> On 11/10/2016 18:33, Andriy Gapon wrote:
>>>> On 10/11/2016 18:12, Henri Hennebert wrote:
>>>>> On 11/10/2016 16:54, Andriy Gapon wrote:
>>>>>> On 10/11/2016 17:20, Henri Hennebert wrote:
>>>>>>> On 11/10/2016 15:00, Andriy Gapon wrote:
>>>>>>>> Interesting. I can not spot any suspicious thread that would hold the
>>>>>>>> vnode
>>>>>>>> lock. Could you please run kgdb (just like that, no arguments), then
>>>>>>>> execute
>>>>>>>> 'bt' command and then select a frame when _vn_lock is called with 'fr
>>>>>>>> N'
>>>>>>>> command. Then please 'print *vp' and share the result.
>>>>>>>>
>>>>>>> I Think I miss something in your request:
>>>>>>
>>>>>> Oh, sorry! The very first step should be 'tid 101112' to switch to the
>>>>>> correct
>>>>>> context.
>>>>>>
>>>>>
>>>>> (kgdb) fr 7
>>>>> #7 0x8063c5b3 in _vn_lock (vp=,
>>>>> flags=2121728,
>>>>
>>>> "value optimized out" - not good
>>>>
>>>>> file=,
>>>>> line=) at vnode_if.h:859
>>>>> 859vnode_if.h: No such file or directory.
>>>>> in vnode_if.h
>>>>> (kgdb) print *vp
>>>>
>>>> I am not sure if this output is valid, because of the message above.
>>>> Could you please try to navigate to nearby frames and see if vp itself has
>>>> a
>>>> valid value there. If you can find such a frame please do *vp there.
>>>>
>>>
>>> Does this seems better?
>>
>> Yes!
>>
>>> (kgdb) fr 8
>>> #8 0x8062a5f7 in vget (vp=0xf80049c2c000, flags=2121728,
>>> td=0xf80009ba0500) at /usr/src/sys/kern/vfs_subr.c:2523
>>> 2523if ((error = vn_lock(vp, flags)) != 0) {
>>> (kgdb) print *vp
>>> $1 = {v_tag = 0x813be535 "zfs", v_op = 0x813d0f70, v_data =
>>> 0xf80049c1f420, v_mount = 0xf800093aa660,
>>> v_nmntvnodes = {tqe_next = 0xf80049c2c938, tqe_prev =
>>> 0xf80049c2bb30},
>>> v_un = {vu_mount = 0x0, vu_socket = 0x0,
>>> vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev
>>> =
>>> 0x0}, v_cache_src = {lh_first = 0x0}, v_cache_dst = {
>>> tqh_first = 0xf800bfc8e3f0, tqh_last = 0xf800bfc8e410},
>>> v_cache_dd =
>>> 0x0, v_lock = {lock_object = {
>>> lo_name = 0x813be535 "zfs", lo_flags = 117112832, lo_data = 0,
>>> lo_witness = 0x0}, lk_lock = 23, lk_exslpfail = 0,
>>> lk_timo = 51, lk_pri = 96}, v_interlock = {lock_object = {lo_name =
>>> 0x8099e9e0 "vnode interlock", lo_flags = 16973824,
>>> lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, v_vnlock =
>>> 0xf80049c2c068, v_actfreelist = {
>>> tqe_next = 0xf80049c2c938, tqe_prev = 0xf80049ae9bd0}, v_bufobj
>>> =
>>> {bo_lock = {lock_object = {
>>> lo_name = 0x8099e9f0 "bufobj interlock", lo_flags =
>>> 86179840,
>>> lo_data = 0, lo_witness = 0x0}, rw_lock = 1},
>>> bo_ops = 0x80c4bf70, bo_object = 0xf800b62e9c60,
>>> bo_synclist =
>>> {le_next = 0x0, le_prev = 0x0},
>>> bo_private = 0xf80049c2c000, __bo_vnode = 0xf80049c2c000,
>>> bo_clean =
>>> {bv_hd = {tqh_first = 0x0,
>>> tqh_last = 0xf80049c2c120}, bv_root = {pt_root = 0}, bv_cnt =
>>> 0},
>>> bo_dirty = {bv_hd = {tqh_first = 0x0,
>>> tqh_last = 0xf80049c2c140}, bv_root = {pt_root = 0}, bv_cnt =
>>> 0},
>>> bo_numoutput = 0, bo_flag = 0, bo_bsize = 131072},
>>> v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters =
>>> {tqh_first = 0x0, tqh_last = 0xf80049c2c188},
>>> rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0,
>>> v_holdcnt = 9, v_usecount = 6, v_iflag = 512,
>>> v_vflag = 32, v_writecount = 0, v_hash = 4833984, v_type = VREG}
>>> (kgdb)
>>
>> flags=2121728 = 0x206000 = LK_SHARED | LK_VNHELD | LK_NODDLKTREAT
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 10/11/2016 19:55, Henri Hennebert wrote:
>
>
> On 11/10/2016 18:33, Andriy Gapon wrote:
>> On 10/11/2016 18:12, Henri Hennebert wrote:
>>> On 11/10/2016 16:54, Andriy Gapon wrote:
>>>> On 10/11/2016 17:20, Henri Hennebert wrote:
>>>>> On 11/10/2016 15:00, Andriy Gapon wrote:
>>>>>> Interesting. I can not spot any suspicious thread that would hold the
>>>>>> vnode
>>>>>> lock. Could you please run kgdb (just like that, no arguments), then
>>>>>> execute
>>>>>> 'bt' command and then select a frame when _vn_lock is called with 'fr N'
>>>>>> command. Then please 'print *vp' and share the result.
>>>>>>
>>>>> I Think I miss something in your request:
>>>>
>>>> Oh, sorry! The very first step should be 'tid 101112' to switch to the
>>>> correct
>>>> context.
>>>>
>>>
>>> (kgdb) fr 7
>>> #7 0x8063c5b3 in _vn_lock (vp=, flags=2121728,
>>
>> "value optimized out" - not good
>>
>>> file=,
>>> line=) at vnode_if.h:859
>>> 859vnode_if.h: No such file or directory.
>>> in vnode_if.h
>>> (kgdb) print *vp
>>
>> I am not sure if this output is valid, because of the message above.
>> Could you please try to navigate to nearby frames and see if vp itself has a
>> valid value there. If you can find such a frame please do *vp there.
>>
>
> Does this seems better?
Yes!
> (kgdb) fr 8
> #8 0x8062a5f7 in vget (vp=0xf80049c2c000, flags=2121728,
> td=0xf80009ba0500) at /usr/src/sys/kern/vfs_subr.c:2523
> 2523if ((error = vn_lock(vp, flags)) != 0) {
> (kgdb) print *vp
> $1 = {v_tag = 0x813be535 "zfs", v_op = 0x813d0f70, v_data =
> 0xf80049c1f420, v_mount = 0xf800093aa660,
> v_nmntvnodes = {tqe_next = 0xf80049c2c938, tqe_prev =
> 0xf80049c2bb30},
> v_un = {vu_mount = 0x0, vu_socket = 0x0,
> vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev =
> 0x0}, v_cache_src = {lh_first = 0x0}, v_cache_dst = {
> tqh_first = 0xf800bfc8e3f0, tqh_last = 0xf800bfc8e410},
> v_cache_dd =
> 0x0, v_lock = {lock_object = {
> lo_name = 0x813be535 "zfs", lo_flags = 117112832, lo_data = 0,
> lo_witness = 0x0}, lk_lock = 23, lk_exslpfail = 0,
> lk_timo = 51, lk_pri = 96}, v_interlock = {lock_object = {lo_name =
> 0x8099e9e0 "vnode interlock", lo_flags = 16973824,
> lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, v_vnlock =
> 0xf80049c2c068, v_actfreelist = {
> tqe_next = 0xf80049c2c938, tqe_prev = 0xf80049ae9bd0}, v_bufobj =
> {bo_lock = {lock_object = {
> lo_name = 0x8099e9f0 "bufobj interlock", lo_flags = 86179840,
> lo_data = 0, lo_witness = 0x0}, rw_lock = 1},
> bo_ops = 0x80c4bf70, bo_object = 0xf800b62e9c60, bo_synclist =
> {le_next = 0x0, le_prev = 0x0},
> bo_private = 0xf80049c2c000, __bo_vnode = 0xf80049c2c000,
> bo_clean =
> {bv_hd = {tqh_first = 0x0,
> tqh_last = 0xf80049c2c120}, bv_root = {pt_root = 0}, bv_cnt = 0},
> bo_dirty = {bv_hd = {tqh_first = 0x0,
> tqh_last = 0xf80049c2c140}, bv_root = {pt_root = 0}, bv_cnt = 0},
> bo_numoutput = 0, bo_flag = 0, bo_bsize = 131072},
> v_pollinfo = 0x0, v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters =
> {tqh_first = 0x0, tqh_last = 0xf80049c2c188},
> rl_currdep = 0x0}, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0,
> v_holdcnt = 9, v_usecount = 6, v_iflag = 512,
> v_vflag = 32, v_writecount = 0, v_hash = 4833984, v_type = VREG}
> (kgdb)
flags=2121728 = 0x206000 = LK_SHARED | LK_VNHELD | LK_NODDLKTREAT
lk_lock = 23 = 0x17 = LK_ONE_SHARER | LK_EXCLUSIVE_WAITERS | LK_SHARED_WAITERS |
LK_SHARE
So, here's what we have here: this thread tries to get a shared lock on the
vnode, the vnode is already locked in shared mode, but there is an exclusive
waiter (or, perhaps, multiple waiters). So, this thread can not get the lock
because of the exclusive waiter. And I do not see an easy way to identify that
waiter.
In the procstat output that you provided earlier there was no other thread in
vn_lock. Hmm, I see this:
procstat: sysctl: kern.proc.kstack: 14789: Device busy
procstat: sysctl: kern.proc.kstack: 82034: Device busy
Could you please check what those two processes are (if they are still running)?
Perhaps try procstat for each of the pids several times.
--
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"
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 10/11/2016 18:12, Henri Hennebert wrote:
> On 11/10/2016 16:54, Andriy Gapon wrote:
>> On 10/11/2016 17:20, Henri Hennebert wrote:
>>> On 11/10/2016 15:00, Andriy Gapon wrote:
>>>> Interesting. I can not spot any suspicious thread that would hold the
>>>> vnode
>>>> lock. Could you please run kgdb (just like that, no arguments), then
>>>> execute
>>>> 'bt' command and then select a frame when _vn_lock is called with 'fr N'
>>>> command. Then please 'print *vp' and share the result.
>>>>
>>> I Think I miss something in your request:
>>
>> Oh, sorry! The very first step should be 'tid 101112' to switch to the
>> correct
>> context.
>>
>
> (kgdb) fr 7
> #7 0x8063c5b3 in _vn_lock (vp=, flags=2121728,
"value optimized out" - not good
> file=,
> line=) at vnode_if.h:859
> 859vnode_if.h: No such file or directory.
> in vnode_if.h
> (kgdb) print *vp
I am not sure if this output is valid, because of the message above.
Could you please try to navigate to nearby frames and see if vp itself has a
valid value there. If you can find such a frame please do *vp there.
> $1 = {v_tag = 0x80faeb78 "â~\231\200", v_op = 0xf80009a41000,
> v_data = 0x0, v_mount = 0xf80009a41010,
> v_nmntvnodes = {tqe_next = 0x0, tqe_prev = 0x80edc088}, v_un =
> {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0,
> vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0xf80009466e90, le_prev =
> 0x0}, v_cache_src = {lh_first = 0xfe010186d768},
> v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfeb8a7c0}, v_cache_dd =
> 0xf8000284f000, v_lock = {lock_object = {
> lo_name = 0xf8002c00ee80 "", lo_flags = 0, lo_data = 0, lo_witness =
> 0xf800068bd480},
> lk_lock = 1844673520268056, lk_exslpfail = 153715840, lk_timo = -2048,
> lk_pri = 0}, v_interlock = {lock_object = {
> lo_name = 0x18af8 address>, lo_flags = 0, lo_data = 0,
> lo_witness = 0x0}, mtx_lock = 0}, v_vnlock = 0x0, v_actfreelist =
> {tqe_next = 0x0, tqe_prev = 0xf80009ba05c0},
> v_bufobj = {bo_lock = {lock_object = {lo_name = 0xf80009a41000 "",
> lo_flags = 1, lo_data = 0, lo_witness = 0x400ff},
> rw_lock = 2}, bo_ops = 0x1, bo_object = 0xf80049c2c068,
> bo_synclist = {le_next = 0x813be535,
> le_prev = 0x1}, bo_private = 0x0, __bo_vnode = 0x0,
> bo_clean =
> {bv_hd = {tqh_first = 0x0, tqh_last = 0x0},
> bv_root = {pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first =
> 0xf80088ac8d00, tqh_last = 0xf8003cc5b600},
> bv_root = {pt_root = 2553161591}, bv_cnt = -1741805705}, bo_numoutput =
> 31, bo_flag = 0, bo_bsize = 0}, v_pollinfo = 0x0,
> v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0xf88,
> tqh_last = 0x19cc}, rl_currdep = 0x3f8},
> v_cstart = 16256, v_lasta = 679, v_lastw = 0, v_clen = 0, v_holdcnt = 0,
> v_usecount = 2369, v_iflag = 0, v_vflag = 0,
> v_writecount = 0, v_hash = 0, v_type = VNON}
> (kgdb)
>
> Thanks for your time
>
> Henri
--
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"
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 10/11/2016 17:20, Henri Hennebert wrote: > On 11/10/2016 15:00, Andriy Gapon wrote: >> Interesting. I can not spot any suspicious thread that would hold the vnode >> lock. Could you please run kgdb (just like that, no arguments), then execute >> 'bt' command and then select a frame when _vn_lock is called with 'fr N' >> command. Then please 'print *vp' and share the result. >> > I Think I miss something in your request: Oh, sorry! The very first step should be 'tid 101112' to switch to the correct context. > [root@avoriaz ~]# kgdb > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from > /usr/lib/debug//boot/kernel/zfs.ko.debug...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from > /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done. > done. > > --- clip --- > > Loaded symbols for /boot/kernel/accf_data.ko > Reading symbols from /boot/kernel/daemon_saver.ko...Reading symbols from > /usr/lib/debug//boot/kernel/daemon_saver.ko.debug...done. > done. > Loaded symbols for /boot/kernel/daemon_saver.ko > #0 sched_switch (td=0xf8001131da00, newtd=0xf800762a8500, > flags= optimized out>) > at /usr/src/sys/kern/sched_ule.c:1973 > 1973cpuid = PCPU_GET(cpuid); > (kgdb) bt > #0 sched_switch (td=0xf8001131da00, newtd=0xf800762a8500, > flags= optimized out>) > at /usr/src/sys/kern/sched_ule.c:1973 > #1 0x80566b15 in tc_fill_vdso_timehands32 (vdso_th32=0x0) at > /usr/src/sys/kern/kern_tc.c:2121 > #2 0x80555227 in timekeep_push_vdso () at > /usr/src/sys/kern/kern_sharedpage.c:174 > #3 0x80566226 in tc_windup () at /usr/src/sys/kern/kern_tc.c:1426 > #4 0x804eaa41 in hardclock_cnt (cnt=1, usermode= out>) > at /usr/src/sys/kern/kern_clock.c:589 > #5 0x808fac74 in handleevents (now=, fake=0) at > /usr/src/sys/kern/kern_clocksource.c:223 > #6 0x808fb1d7 in timercb (et=0x8100cf20, arg= out>) at /usr/src/sys/kern/kern_clocksource.c:352 > #7 0xf800b6429a00 in ?? () > #8 0x81051080 in vm_page_array () > #9 0x81051098 in vm_page_queue_free_mtx () > #10 0xfe0101818920 in ?? () > #11 0x805399c0 in __mtx_lock_sleep (c=, tid=Error > accessing memory address 0xffac: Bad add\ > ress. > ) at /usr/src/sys/kern/kern_mutex.c:590 > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) q > [root@avoriaz ~]# > > I don't find the requested frame > > Henri -- 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"
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 10/11/2016 12:30, Henri Hennebert wrote: > On 11/10/2016 11:21, Andriy Gapon wrote: >> On 09/11/2016 15:58, Eric van Gyzen wrote: >>> On 11/09/2016 07:48, Henri Hennebert wrote: >>>> I encounter a strange deadlock on >>>> >>>> FreeBSD avoriaz.restart.bel 11.0-RELEASE-p3 FreeBSD 11.0-RELEASE-p3 #0 >>>> r308260: >>>> Fri Nov 4 02:51:33 CET 2016 >>>> r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 >>>> >>>> This system is exclusively running on zfs. >>>> >>>> After 3 or 4 days, `periodic daily` is locked in the directory >>>> /usr/local/news/bin >>>> >>>> [root@avoriaz ~]# ps xa|grep find >>>> 85656 - D0:01.13 find / ( ! -fstype local -o -fstype rdonly ) >>>> -prune >>>> -o ( -name [#,]* -o -name .#* -o -name a.out -o -nam >>>> 462 1 S+ 0:00.00 grep find >>>> [root@avoriaz ~]# procstat -f 85656 >>>> PID COMMFD T V FLAGSREF OFFSET PRO NAME >>>> 85656 find text v r r--- - - - /usr/bin/find >>>> 85656 find cwd v d r--- - - - /usr/local/news/bin >>>> 85656 find root v d r--- - - - / >>>> 85656 find 0 v c r--- 3 0 - /dev/null >>>> 85656 find 1 p - rw-- 1 0 - - >>>> 85656 find 2 v r -w-- 7 17 - - >>>> 85656 find 3 v d r--- 1 0 - /home/root >>>> 85656 find 4 v d r--- 1 0 - /home/root >>>> 85656 find 5 v d rn-- 1 533545184 - >>>> /usr/local/news/bin >>>> [root@avoriaz ~]# >>>> >>>> If I try `ls /usr/local/news/bin` it is also locked. >>>> >>>> After `shutdown -r now` the system remain locked after the line '0 0 0 0 0 >>>> 0' >>>> >>>> After a reset and reboot I can access /usr/local/news/bin. >>>> >>>> I delete this directory and reinstall the package `portupgrade -fu >>>> news/inn` >>>> >>>> 5 days later `periodic daily`is locked on the same directory :-o >>>> >>>> Any idea? >>> >>> I can't help with the deadlock, but someone who _can_ help will probably >>> ask for >>> the output of "procstat -kk PID" with the PID of the "find" process. >> >> In fact, it's procstat -kk -a. With just one thread we would see that a >> thread >> is blocked on something, but we won't see why that something can not be >> acquired. >> >> > I attach the result, Interesting. I can not spot any suspicious thread that would hold the vnode lock. Could you please run kgdb (just like that, no arguments), then execute 'bt' command and then select a frame when _vn_lock is called with 'fr N' command. Then please 'print *vp' and share the result. -- 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"
Re: Freebsd 11.0 RELEASE - ZFS deadlock
On 09/11/2016 15:58, Eric van Gyzen wrote: > On 11/09/2016 07:48, Henri Hennebert wrote: >> I encounter a strange deadlock on >> >> FreeBSD avoriaz.restart.bel 11.0-RELEASE-p3 FreeBSD 11.0-RELEASE-p3 #0 >> r308260: >> Fri Nov 4 02:51:33 CET 2016 >> r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 >> >> This system is exclusively running on zfs. >> >> After 3 or 4 days, `periodic daily` is locked in the directory >> /usr/local/news/bin >> >> [root@avoriaz ~]# ps xa|grep find >> 85656 - D0:01.13 find / ( ! -fstype local -o -fstype rdonly ) >> -prune >> -o ( -name [#,]* -o -name .#* -o -name a.out -o -nam >> 462 1 S+ 0:00.00 grep find >> [root@avoriaz ~]# procstat -f 85656 >> PID COMMFD T V FLAGSREF OFFSET PRO NAME >> 85656 find text v r r--- - - - /usr/bin/find >> 85656 find cwd v d r--- - - - /usr/local/news/bin >> 85656 find root v d r--- - - - / >> 85656 find 0 v c r--- 3 0 - /dev/null >> 85656 find 1 p - rw-- 1 0 - - >> 85656 find 2 v r -w-- 7 17 - - >> 85656 find 3 v d r--- 1 0 - /home/root >> 85656 find 4 v d r--- 1 0 - /home/root >> 85656 find 5 v d rn-- 1 533545184 - /usr/local/news/bin >> [root@avoriaz ~]# >> >> If I try `ls /usr/local/news/bin` it is also locked. >> >> After `shutdown -r now` the system remain locked after the line '0 0 0 0 0 0' >> >> After a reset and reboot I can access /usr/local/news/bin. >> >> I delete this directory and reinstall the package `portupgrade -fu news/inn` >> >> 5 days later `periodic daily`is locked on the same directory :-o >> >> Any idea? > > I can't help with the deadlock, but someone who _can_ help will probably ask > for > the output of "procstat -kk PID" with the PID of the "find" process. In fact, it's procstat -kk -a. With just one thread we would see that a thread is blocked on something, but we won't see why that something can not be acquired. -- 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"
Re: Uppercase RE matching problems in FreeBSD 11
On 06/11/2016 23:30, Stefan Bethke wrote: > Although with en_US.UTF-8 on other systems, I have not had that experience. > A quick check on stuff I have immediate access to: > > macOS 10.12: > $ echo 'abcdABCD' | sed 's/[A-Z]/X/g’ > abcd > > Ubuntu 14.04.5 > $ echo 'abcdABCD' | sed 's/[A-Z]/X/g’ > abcd > > FreeBSD 10-stable > $ echo 'abcdABCD' | sed 's/[A-Z]/X/g' > abcd Latest Gentoo: $ echo 'abcdABCD' | sed 's/[A-Z]/X/g' aXXX Recent OpenIndiana (an illumos based OS): $ echo 'abcdABCD' | sed 's/[A-Z]/X/g' aXXX -- 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"
Re: zfs, a directory that used to hold lot of files and listing pause
Instead of the guesswork and black magic, you could try to use tools to analyze the problem. E.g., determine if the delay is because a CPU does a lot of work or it is because of waiting. Find the bottleneck, etc. pmcstat, dtrace are your friends :-) -- 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"
Re: Repeatable panic on ZFS filesystem (used for backups); 11.0-STABLE
On 18/10/2016 00:43, Steven Hartland wrote: > On 17/10/2016 20:52, Andriy Gapon wrote: >> On 17/10/2016 21:54, Steven Hartland wrote: >>> You're hitting stack exhaustion, have you tried increasing the kernel stack >>> pages? >>> It can be changed from /boot/loader.conf >>> kern.kstack_pages="6" >>> >>> Default on amd64 is 4 IIRC >> Steve, >> >> perhaps you can think of a more proper fix? :-) >> https://lists.freebsd.org/pipermail/freebsd-stable/2016-July/085047.html > Yes need to find some time to have a look at it, but given how rare this is > and > with TRIM being re-implemented upstream in a totally different manor I'm > reticent to spend any real time on it. Fair enough. Especially given that there is only a single affected system reported so far. -- 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"
Re: Repeatable panic on ZFS filesystem (used for backups); 11.0-STABLE
913 >> #165 0x822bf919 in zio_vdev_io_done (zio=0xf800a69523d8) >> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3137 >> #166 0x822bbefd in zio_execute (zio=) >> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1651 >> #167 0x822bf75d in zio_vdev_io_start (zio=0xf800a69523d8) >> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3112 >> #168 0x822bbefd in zio_execute (zio=) >> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1651 >> #169 0x822a216d in vdev_queue_io_done (zio=) >> at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:913 >> #170 0x822bf919 in zio_vdev_io_done (zio=0xf8056e47c000) >> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3137 >> #171 0x822bbefd in zio_execute (zio=) >> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1651 >> #172 0x822bf75d in zio_vdev_io_start (zio=0xf8056e47c000) >> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3112 >> #173 0x822bbefd in zio_execute (zio=) >> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1651 >> #174 0x822a216d in vdev_queue_io_done (zio=) >> at >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:913 >> #175 0x822bf919 in zio_vdev_io_done (zio=0xf800b17b23d8) >> at /usr/src/sys/cddl/contrib/opensolaris/
Re: aibs(4) / atk0110 support for newer systems
On 14/10/2016 21:49, Torfinn Ingolfsen wrote: > On Tue, 11 Oct 2016 14:29:34 +0300 > Andriy Gapon <a...@freebsd.org> wrote: > >> On 06/10/2016 00:37, Andriy Gapon wrote: >>> On 05/10/2016 23:28, Torfinn Ingolfsen wrote: >>>> #6 0x80cd0081 in calltrap () >>>> at /usr/src/sys/amd64/amd64/exception.S:238 >>>> #7 0x81bcb078 in aibs_add_sensor () from /boot/kernel/aibs.ko >>>> #8 0x81bcb4b4 in aibs_attach_sif () from /boot/kernel/aibs.ko >>> >>> Argh, I've just spotted a very silly typo. >>> Could you please replace '0' with 'o' in >>> err = aibs_add_sensor(sc, 0, [i], ); >>> ? >> >> Ping. > > Done - see other messages in this thread. Sorry about the delay. > No worries. Thank you very much for your testing! I've just committed the change to head. -- 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"
Re: ZFS l2arc broken in 10.3
On 12/10/2016 23:18, Peter wrote:
> Details:
> After upgrading 2 machines from 9.3 to 10.3-STABLE, on one of them the
> l2arc stays empty (capacity alloc = 0), although it is online and gets
> accessed. It did work well on 9.3.
>
> I did the following tests:
> * Create a zpool on a stick, with two volumes: one filesystem and one
>cache. The cache stays with alloc=0.
>Export it and move it into the other machine. The cache immediately
>fills.
>Move it back, the cache stays with alloc=0.
>-> this rules out all zpool/zfs get/set options, as they should
> walk with the pool.
> * Boot the GENERIC kernel. l2arc stays with alloc=0.
>-> this rules out all my nonstandard kernel options.
> * Boot in single user mode. l2arc stays with alloc=0.
>-> this rules out all /etc/* config files.
> * Delete the zpool.cache and reimport pools. l2arc stays with alloc=0.
> * Copy the /boot/loader.conf settings to the other machine. The l2arc
>still works there.
>
> I could not think of any remaining place where this could come from,
> except the kernel code itself.
> From there, I found these counters nicely incrementing each second:
> kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 50758
> kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 27121
> kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 40589375488
> But also this counter incrementing:
> kstat.zfs.misc.arcstats.l2_write_full: 14604
>
> Then with some printf in the code I saw these values provided:
> buf_sz = hdr->b_size;
> align = (size_t)1 << dev->l2ad_vdev->vdev_ashift;
> buf_a_sz = P2ROUNDUP(buf_sz, align);
> if ((write_asize + buf_a_sz) > target_sz) {
>full = B_TRUE;
>mutex_exit(hash_lock);
>ARCSTAT_BUMP(arcstat_l2_write_full);
>break;
> }
>
> buf_sz =1536
> align =512
> buf_a_sz =18446744069414585856
> write_asize =0
> target_sz =16777216
>
> where buf_a_sz is obviousely off by (2^64 - 2^32).
>
> Maybe this is an effect of crosscompiling i386 on amd64.
Yes, the problem is specific to 32-bit platforms where size_t is 32-bit.
> But anyway, as long as
> i386 is still supported, it should not happen.
Certainly.
> Now, my real concern is: if this really obvious ... made it undetected until
> 10.3, how many other missing typecasts are still in the code??
No need to be dramatic here. That particular piece code is very new.
I committed it to head in April (r297848), MFC-ed even later.
Apparently no one else who uses 32-bit systems and has L2ARC configured had a
chance to run into the bug.
Thank you very much for discovering and analyzing the bug and providing a fix
for it!
--
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"
Re: 11-RELEASE PL1 doesn't load kernel modules with ZFS-on-Root
On 13/10/2016 07:04, Aryeh Friedman wrote: > Please check dmesg(8) > for more details. -- 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"
Re: aibs(4) / atk0110 support for newer systems
On 06/10/2016 00:37, Andriy Gapon wrote: > On 05/10/2016 23:28, Torfinn Ingolfsen wrote: >> #6 0x80cd0081 in calltrap () >> at /usr/src/sys/amd64/amd64/exception.S:238 >> #7 0x81bcb078 in aibs_add_sensor () from /boot/kernel/aibs.ko >> #8 0x81bcb4b4 in aibs_attach_sif () from /boot/kernel/aibs.ko > > Argh, I've just spotted a very silly typo. > Could you please replace '0' with 'o' in > err = aibs_add_sensor(sc, 0, [i], ); > ? Ping. -- 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"
Re: aibs(4) / atk0110 support for newer systems
On 05/10/2016 23:28, Torfinn Ingolfsen wrote: > #6 0x80cd0081 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:238 > #7 0x81bcb078 in aibs_add_sensor () from /boot/kernel/aibs.ko > #8 0x81bcb4b4 in aibs_attach_sif () from /boot/kernel/aibs.ko Argh, I've just spotted a very silly typo. Could you please replace '0' with 'o' in err = aibs_add_sensor(sc, 0, [i], ); ? I wish compilers were more noisy about passing a scalar as a pointer argument. Thanks! -- 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"
Re: aibs(4) / atk0110 support for newer systems
On 05/10/2016 23:28, Torfinn Ingolfsen wrote: > On Wed, 5 Oct 2016 16:09:40 +0300 > Andriy Gapon <a...@freebsd.org> wrote: > >> >> Seems like this is a clang vs gcc issue as I didn't get warnings here. >> Could you please simply add initialization to those variables in >> aibs_attach_ggrp()? >> E.g.: >> s_idx = NULL; >> so = NULL; > > I ended up adding > s_idx = NULL; > so = NULL; > name = NULL; > > to aibs_attach_ggrp(), that made the module compile. Okay, thank for letting me know. > Unfortunately, my machines panics as soon as this module is loaded: Not good... > root@kg-core1# cat /var/crash/info.0 > Dump header from device /dev/ada0p3 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 1466040320B (1398 MB) > Blocksize: 512 > Dumptime: Wed Oct 5 21:48:42 2016 > Hostname: kg-core1.kg4.no > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 9.3-STABLE #3 r304838: Fri Aug 26 12:11:25 CEST 2016 > r...@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC > Panic String: page fault > Dump Parity: 1914870814 > Bounds: 0 > Dump Status: good > > core.txt.0 attached > HTH Seems like the module got built without debug symbols. Please try make KERNBUILDDIR=/usr/obj/... -- 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"
Re: aibs(4) / atk0110 support for newer systems
On 05/10/2016 23:28, Torfinn Ingolfsen wrote: > Unfortunately, my machines panics as soon as this module is loaded: Not good... > (kgdb) #0 doadump (textdump=) at pcpu.h:235 > #1 0x80900b06 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:454 > #2 0x80901007 in panic (fmt=0x1 ) > at /usr/src/sys/kern/kern_shutdown.c:642 > #3 0x80ce6887 in trap_fatal (frame=0xc, eva=) > at /usr/src/sys/amd64/amd64/trap.c:876 > #4 0x80ce6bd1 in trap_pfault (frame=0xff88b8554380, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:798 > #5 0x80ce7199 in trap (frame=0xff88b8554380) > at /usr/src/sys/amd64/amd64/trap.c:462 > #6 0x80cd0081 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:238 > #7 0x81bcb078 in aibs_add_sensor () from /boot/kernel/aibs.ko > #8 0x81bcb4b4 in aibs_attach_sif () from /boot/kernel/aibs.ko > #9 0x81bcb901 in aibs_attach () from /boot/kernel/aibs.ko I see that line numbers are not reported for the module, so it probably lacks debug symbols. But it seems that you compile your kernel with them. Please try to compile the module using make KERNBUILDDIR=/usr/obj/... > #10 0x8093424c in device_attach (dev=0x0) at device_if.h:180 > #11 0x8033bd43 in acpi_driver_added (dev=, > driver=) at /usr/src/sys/dev/acpica/acpi.c:841 > #12 0x809323d5 in devclass_driver_added (dc=0xfe00093c5900, > driver=0x81bcbe9c) at bus_if.h:204 > #13 0x80932f13 in devclass_add_driver (dc=0xfe00093c5900, > driver=0x81bcc140, pass=2147483647, dcp=0x81bcc1e0) > at /usr/src/sys/kern/subr_bus.c:1086 > #14 0x808ebef8 in module_register_init (arg=) > at /usr/src/sys/kern/kern_module.c:123 > #15 0x808e38ae in linker_load_module (kldname=, > modname=0xfe03ec774000 "aibs", parent=0x0, verinfo=0x0, > lfpp=0xff88b8554aa0) at /usr/src/sys/kern/kern_linker.c:233 > #16 0x808e3fc4 in kern_kldload (td=, > file=0xfe03ec774000 "aibs", fileid=0xff88b8554af4) > at /usr/src/sys/kern/kern_linker.c:1038 > #17 0x808e40d4 in sys_kldload (td=0xfe020f434490, > uap=) at /usr/src/sys/kern/kern_linker.c:1064 > #18 0x80ce5ffa in amd64_syscall (td=0xfe020f434490, traced=0) > at subr_syscall.c:142 > #19 0x80cd0367 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:398 > #20 0x00080085d10c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) ___ 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"
iicsmb
Does anyone use iicsmb driver for any practical purposes? Or more broadly, does anyone have a system with an I2C controller behind which SMBus-compatible slaves are known to exist? -- 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"
Re: aibs(4) / atk0110 support for newer systems
On 05/10/2016 15:37, Torfinn Ingolfsen wrote: > On Mon, 3 Oct 2016 23:05:48 +0300 > Andriy Gapon <a...@freebsd.org> wrote: > >> Yes, it does. Thank you! >> It seems like a couple of minor changes are not in the source tree that you >> are >> using. One is some casts in a diagnostic printf and the other is a different >> rounding of 0C in Kelvins. >> I've generated a patch that should apply to your tree: >> https://people.freebsd.org/~avg/aibs-ggrp-gitm.93.diff >> Please try. > > The patch applied cleanly (I removed the old one with patch -R first): Good! > /usr/src/sys/modules/acpi/aibs/../../../dev/acpi_support/atk0110.c: In > function 'aibs_attach': > /usr/src/sys/modules/acpi/aibs/../../../dev/acpi_support/atk0110.c:252: > warning: 's_idx' may be used uninitialized in this function > /usr/src/sys/modules/acpi/aibs/../../../dev/acpi_support/atk0110.c:252: note: > 's_idx' was declared here > /usr/src/sys/modules/acpi/aibs/../../../dev/acpi_support/atk0110.c:256: > warning: 'so' may be used uninitialized in this function > /usr/src/sys/modules/acpi/aibs/../../../dev/acpi_support/atk0110.c:256: note: > 'so' was declared here > /usr/src/sys/modules/acpi/aibs/../../../dev/acpi_support/atk0110.c:253: > warning: 'name' may be used uninitialized in this function > /usr/src/sys/modules/acpi/aibs/../../../dev/acpi_support/atk0110.c:253: note: > 'name' was declared here > *** [atk0110.o] Error code 1 > > Stop in /usr/src/sys/modules/acpi/aibs. > > Do I have to do something more in order to build the new module? > Seems like this is a clang vs gcc issue as I didn't get warnings here. Could you please simply add initialization to those variables in aibs_attach_ggrp()? E.g.: s_idx = NULL; so = NULL; Thank you! -- 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"
Re: Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
I've written a patch that implements zfs_vptocnp() using z_parent property. The new code should be 100% reliable for directories and "mostly" reliable for files (that is, when hardlinks across directories are not used). Could you please review / test it? https://reviews.freebsd.org/D8146 Thanks! -- 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"
Re: aibs(4) / atk0110 support for newer systems
On 03/10/2016 21:15, Torfinn Ingolfsen wrote: > Sorry for the delay. I was distracted by other things. > root@kg-core1# cd / > root@kg-core1# patch -p1 < /home/tingo/dl/aibs-ggrp-gitm.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |diff --git a/sys/dev/acpi_support/atk0110.c b/sys/dev/acpi_support/atk0110.c > |index e79a0e00e3577..743684100f737 100644 > |--- a/sys/dev/acpi_support/atk0110.c > |+++ b/sys/dev/acpi_support/atk0110.c > -- > Patching file sys/dev/acpi_support/atk0110.c using Plan A... > Hunk #1 succeeded at 28. > Hunk #2 succeeded at 52. > Hunk #3 succeeded at 78. > Hunk #4 succeeded at 124. > Hunk #5 succeeded at 362. > Hunk #6 succeeded at 370. > Hunk #7 failed at 391. > Hunk #8 succeeded at 435. > Hunk #9 succeeded at 450. > Hunk #10 failed at 488. > 2 out of 10 hunks failed--saving rejects to sys/dev/acpi_support/atk0110.c.rej > HTH Yes, it does. Thank you! It seems like a couple of minor changes are not in the source tree that you are using. One is some casts in a diagnostic printf and the other is a different rounding of 0C in Kelvins. I've generated a patch that should apply to your tree: https://people.freebsd.org/~avg/aibs-ggrp-gitm.93.diff Please try. -- 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"
Re: aibs(4) / atk0110 support for newer systems
On 30/09/2016 21:59, Torfinn Ingolfsen wrote: > As I used '-C' as an argument to patch, there isn't one: > root@kg-core1# l /sys/dev/acpi_support/atk0110.c.rej > ls: /sys/dev/acpi_support/atk0110.c.rej: No such file or directory Right. So, I guess I have to specifically ask to not use -C option? :-) -- 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"
Re: aibs(4) / atk0110 support for newer systems
On 30/09/2016 19:03, Mark Dixon wrote: > Hi Andriy, > > I tried your patch on an Asus Z170-Deluxe on 11-RELEASEt and aibs did > not seem to pick up anything before or after. Not 100% what sensors > this board has. If acpidump -d | fgrep ATK0110 doesn't produce any result, then there is no chance of the driver working. Otherwise I would be interested in a full acpidump -dt output. -- 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"
Re: aibs(4) / atk0110 support for newer systems
On 30/09/2016 15:57, Torfinn Ingolfsen wrote: > On Fri, 30 Sep 2016 14:30:02 +0300 > Andriy Gapon <a...@freebsd.org> wrote: > >> Testing the patch should be as easy as building, installing and loading aibs >> module (found in sys/modules/acpi/aibs). Well, also don't forget to apply >> the >> patch with patch -p1 :-) > > The patch doesn't apply cleanly on FreeBSD 9.3-stable: > root@kg-core1# patch -C -p1 < /home/tingo/dl/aibs-ggrp-gitm.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |diff --git a/sys/dev/acpi_support/atk0110.c b/sys/dev/acpi_support/atk0110.c > |index e79a0e00e3577..743684100f737 100644 > |--- a/sys/dev/acpi_support/atk0110.c > |+++ b/sys/dev/acpi_support/atk0110.c > -- > Patching file sys/dev/acpi_support/atk0110.c using Plan A... > Hunk #1 succeeded at 28. > Hunk #2 succeeded at 52. > Hunk #3 succeeded at 78. > Hunk #4 succeeded at 124. > Hunk #5 succeeded at 362. > Hunk #6 succeeded at 370. > Hunk #7 failed at 391. > Hunk #8 succeeded at 435. > Hunk #9 succeeded at 450. > Hunk #10 failed at 488. > 2 out of 10 hunks failed--saving rejects to sys/dev/acpi_support/atk0110.c.rej > done > > I'm running > root@kg-core1# uname -a > FreeBSD kg-core1.kg4.no 9.3-STABLE FreeBSD 9.3-STABLE #3 r304838: Fri Aug 26 > 12:11:25 CEST 2016 r...@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC > amd64 Please show the .rej file. Perhaps gpatch --merge=diff3 would work better than the base system patch if the conflicts are trivial enough. -- 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"
aibs(4) / atk0110 support for newer systems
I've written a patch for aibs(4) (also known as ASUS AI Booster and ATK0110)
that adds support for discovering and querying sensors using newer GGRP ("get
group"?) and GITM ("get item"?) methods:
https://people.freebsd.org/~avg/aibs-ggrp-gitm.diff
If you are using the driver could you please test that the patch does not break
it for you?
If you have an ASUS motherboard where aibs does not find sensors could you
please check if there is any improvement with the patch?
Testing the patch should be as easy as building, installing and loading aibs
module (found in sys/modules/acpi/aibs). Well, also don't forget to apply the
patch with patch -p1 :-)
--
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"
Re: X2APIC support
On 14/09/2016 19:08, Konstantin Belousov wrote: > Well, the following might work, but I have no good idea what to do > when BIOS does handoff with x2APIC enabled and directs us to not > enable it. Switching to xAPIC mode is not an option, I suspect. The specification describes a way to transition from x2APIC to xAPIC mode, but it's not trivial, because it requires checking all CPU IDs and disabling CPUs with too high ones. Personally, I am not comfortable with your patch. First, it seems that the patch does not cover hw.x2apic_enable=0. And I don't like that we leave x2APIC mode enabled even when we otherwise would not enable it just because BIOS. All in all, if we can't go x2APIC -> xAPIC, then I would prefer a meaningful panic over a "compromise". Just my opinion. The topic probably warrants a wider discussion and a proper review. Slawa, thank you for your persistence and testing. -- 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"
Re: X2APIC support
On 14/09/2016 15:49, Slawa Olhovchenkov wrote: > MSR_APICBASE = 0xfee00d00 > x2APIC is prohibited but turned on by BIOS Kostik, ^ P.S. the format string for the value should have been 0x%016jx. -- 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"
Re: X2APIC support
On 14/09/2016 15:33, Slawa Olhovchenkov wrote:
> On Wed, Sep 14, 2016 at 03:22:17PM +0300, Andriy Gapon wrote:
>
>> On 14/09/2016 14:36, Konstantin Belousov wrote:
>>> On Tue, Sep 13, 2016 at 06:52:19PM +0300, Andriy Gapon wrote:
>>>> On 13/09/2016 18:22, Konstantin Belousov wrote:
>>>>> Any access
>>>>> to the LAPIC registers page in x2APIC mode faults.
>>>>
>>>> Is this a fact?
>>>> I read the following in the specification:
>>>>
>>>> In x2APIC mode, the memory mapped interface is not available and any
>>>> access to the MMIO interface will behave similar to that of a legacy
>>>> xAPIC
>>>> in globally disabled state.
>>>>
>>>> But I couldn't find what actually happens for the legacy xAPIC in globally
>>>> disabled state. For AMD processors it is documented that if xAPIC is
>>>> disabled
>>>> then accessing the APIC memory range works the same as accessing the
>>>> regular
>>>> memory. That can be different for Intel processors, of course.
>>>
>>> Look at the native_lapic_init(), very beginning of the function. If
>>> x2apic_mode is non-zero, lapic_map is cleared after DMAP page cache
>>> attributes are changed.
>>
>> Right, but we are talking about the case where x2apic_mode *is zero* while
>> the
>> hardware in x2APIC mode.
>>
>>> Right now, if BIOS pass control to OS in x2APIC mode, thinks just work
>>> because no LAPIC accesses are done until native_lapic_enable_x2apic() is
>>> called. This just happens, I thought about more organized receipt of the
>>> current LAPIC mode. Issue is that decision for LAPIC mode is performed
>>> by madt enumerator which pref. should not read LAPIC config (too early).
>>> And it is not clear at all, what to do if there is reason to use xAPIC,
>>> as checked by madt_setup_local(), but we are in x2APIC mode already.
>>
>> Yes. As I mentioned earlier we should at least panic with an informative
>> message. Maybe we could add some code to so something smarter later.
>>
>>> Anyway, returning to the original issue, I do not believe that the
>>> hand-off on that machine occured in the x2APIC mode when X2APIC_OPT_OUT
>>> is specified. Kernel would fault in that case.
>>
>> I think that it should be easy to check that if Slawa is still willing to try
>> another diagnostic patch.
>
> What combination of BIOS setting need?
The one that causes the crash.
>> diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c
>> index 203e9d00e8acc..37ac03fb9d811 100644
>> --- a/sys/x86/x86/local_apic.c
>> +++ b/sys/x86/x86/local_apic.c
>> @@ -429,6 +429,12 @@ native_lapic_init(vm_paddr_t addr)
>> if (x2apic_mode) {
>> native_lapic_enable_x2apic();
>> lapic_map = NULL;
>> +} else if ((cpu_feature2 & CPUID2_X2APIC) != 0) {
>> +r = rdmsr(MSR_APICBASE);
>> +printf("MSR_APICBASE = 0x%16jx\n", (uintmax_t)r);
>> +if ((r & (APICBASE_X2APIC | APICBASE_ENABLED)) ==
>> +(APICBASE_X2APIC | APICBASE_ENABLED))
>> +printf("x2APIC is prohibited but turned on by BIOS\n");
>> }
>>
>> /* Setup the spurious interrupt handler. */
>>
>>
>>
>> --
>> Andriy Gapon
--
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"
Re: X2APIC support
On 13/09/2016 17:59, Slawa Olhovchenkov wrote: > Goggling on X2APIC_OPT_OUT take same result: other OS in this case > downgrade to xAPIC mode. It still does not make any sense for BIOS to turn on x2APIC and then instruct the OS that x2APIC must not be used. -- 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"
Re: X2APIC support
On 14/09/2016 14:36, Konstantin Belousov wrote:
> On Tue, Sep 13, 2016 at 06:52:19PM +0300, Andriy Gapon wrote:
>> On 13/09/2016 18:22, Konstantin Belousov wrote:
>>> Any access
>>> to the LAPIC registers page in x2APIC mode faults.
>>
>> Is this a fact?
>> I read the following in the specification:
>>
>> In x2APIC mode, the memory mapped interface is not available and any
>> access to the MMIO interface will behave similar to that of a legacy xAPIC
>> in globally disabled state.
>>
>> But I couldn't find what actually happens for the legacy xAPIC in globally
>> disabled state. For AMD processors it is documented that if xAPIC is
>> disabled
>> then accessing the APIC memory range works the same as accessing the regular
>> memory. That can be different for Intel processors, of course.
>
> Look at the native_lapic_init(), very beginning of the function. If
> x2apic_mode is non-zero, lapic_map is cleared after DMAP page cache
> attributes are changed.
Right, but we are talking about the case where x2apic_mode *is zero* while the
hardware in x2APIC mode.
> Right now, if BIOS pass control to OS in x2APIC mode, thinks just work
> because no LAPIC accesses are done until native_lapic_enable_x2apic() is
> called. This just happens, I thought about more organized receipt of the
> current LAPIC mode. Issue is that decision for LAPIC mode is performed
> by madt enumerator which pref. should not read LAPIC config (too early).
> And it is not clear at all, what to do if there is reason to use xAPIC,
> as checked by madt_setup_local(), but we are in x2APIC mode already.
Yes. As I mentioned earlier we should at least panic with an informative
message. Maybe we could add some code to so something smarter later.
> Anyway, returning to the original issue, I do not believe that the
> hand-off on that machine occured in the x2APIC mode when X2APIC_OPT_OUT
> is specified. Kernel would fault in that case.
I think that it should be easy to check that if Slawa is still willing to try
another diagnostic patch.
diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c
index 203e9d00e8acc..37ac03fb9d811 100644
--- a/sys/x86/x86/local_apic.c
+++ b/sys/x86/x86/local_apic.c
@@ -429,6 +429,12 @@ native_lapic_init(vm_paddr_t addr)
if (x2apic_mode) {
native_lapic_enable_x2apic();
lapic_map = NULL;
+ } else if ((cpu_feature2 & CPUID2_X2APIC) != 0) {
+ r = rdmsr(MSR_APICBASE);
+ printf("MSR_APICBASE = 0x%16jx\n", (uintmax_t)r);
+ if ((r & (APICBASE_X2APIC | APICBASE_ENABLED)) ==
+ (APICBASE_X2APIC | APICBASE_ENABLED))
+ printf("x2APIC is prohibited but turned on by BIOS\n");
}
/* Setup the spurious interrupt handler. */
--
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"
Re: X2APIC support
On 13/09/2016 18:22, Konstantin Belousov wrote: > Any access > to the LAPIC registers page in x2APIC mode faults. Is this a fact? I read the following in the specification: In x2APIC mode, the memory mapped interface is not available and any access to the MMIO interface will behave similar to that of a legacy xAPIC in globally disabled state. But I couldn't find what actually happens for the legacy xAPIC in globally disabled state. For AMD processors it is documented that if xAPIC is disabled then accessing the APIC memory range works the same as accessing the regular memory. That can be different for Intel processors, of course. -- 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"
Re: X2APIC support
On 13/09/2016 17:21, Slawa Olhovchenkov wrote: > boot failed: > > set hw.x2apic_enable=0 > loading required module 'krpc' > /boot/kernel.VSTREAM/krpc.ko size 0x2a210 at 0x134e000 > loading required module 'opensolaris' > ^@/boot/kernel.VSTREAM/opensolaris.ko size 0xadb8 at 0x1379000 > /boot/kernel.VSTREAM/if_igb.ko size 0x69f10 at 0x1384000 > can't find 'if_ixgbe' > /boot/kernel.VSTREAM/if_lagg.ko size 0x150c0 at 0x13ee000^M ^@ > +/boot/kernel.VSTREAM/ukbd.ko size 0xe128 at 0x1404000 > loading required module 'usb' > /boot/kernel.VSTREAM/usb.ko size 0x458b0 at 0x1413000^M| > > /boot/kernel.VSTREAM/umass.ko size 0xaa10 at 0x1459000 > /boot/kernel.VSTREAM/accf_http.ko size 0x2710 at 0x1464000 > /boot/kernel.VSTREAM/uhci.ko size 0xd508 at 0x1467000 > /boot/kernel.VSTREAM/ohci.ko size 0xc9d0 at 0x1475000^M > /boot/kernel.VSTREAM/ehci.ko size 0xfc40 at 0x1482000 > /boot/kernel.VSTREAM/xhci.ko size 0x11068 at 0x1492000 > /boot/kernel.VSTREAM/cc_htcp.ko size 0x3a70 at 0x14a4000 > Booting... > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-RELEASE-p305117 #0: Mon Sep 12 20:38:53 MSK 2016 > s...@edge21.int.integros.com:/usr/obj/usr/src/sys/VSTREAM amd64 > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM > 3.8.0) > VT(vga): text 80x25 > CPU: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz (2200.04-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 > > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> > AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM> > AMD Features2=0x121<LAHF,ABM,Prefetch> > Structured Extended > Features=0x21cbfbb<FSGSBASE,TSCADJ,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,NFPUSG,PQE,RDSEED,ADX,SMAP,PROCTRACE> > XSAVE Features=0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr > TSC: P-state invariant, performance statistics > real memory = 137438953472 (131072 MB) > avail memory = 133407973376 (127227 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > boot_cpu_id = 255 > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = ff > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80537e74 > stack pointer = 0x28:0x814b3a60 > frame pointer = 0x28:0x814b3a70 > 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 > KDB: stack backtrace: > #0 0x805272e7 at kdb_backtrace+0x67 > #1 0x804dd662 at vpanic+0x182 > #2 0x804dd4d3 at panic+0x43 > #3 0x807a37a1 at trap_fatal+0x351 > #4 0x807a3993 at trap_pfault+0x1e3 > #5 0x807a2f1c at trap+0x26c > #6 0x80787ca1 at calltrap+0x8 > #7 0x8083b53a at topo_probe+0x61a > #8 0x8078fe93 at cpu_mp_start+0x1c3 > #9 0x805382ca at mp_start+0x3a > #10 0x80465cd8 at mi_startup+0x118 > #11 0x8028dfac at btext+0x2c > Uptime: 1s Thank you! It seems like exactly the same behavior that happens when you toggle that BIOS option. My theory is that in both cases, hw.x2apic_enable=0 and X2APIC_OPT_OUT is on, the BIOS turns on x2APIC mode and transitions to OS in that mode. In the case when X2APIC_OPT_OUT is on it's clearly a BIOS bug. But maybe we could do a little bit better in both cases. At the very least we could detect the situation and panic with a helpful message (e.g. "x2APIC mode is disabled but turn on by BIOS"). Perhaps we could even try to downgrade to xAPIC mode. -- 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"
Re: X2APIC support
On 13/09/2016 15:42, Slawa Olhovchenkov wrote: > On Tue, Sep 13, 2016 at 03:38:17PM +0300, Andriy Gapon wrote: > >> On 13/09/2016 15:11, Slawa Olhovchenkov wrote: >>> On Tue, Sep 13, 2016 at 03:04:13PM +0300, Andriy Gapon wrote: >>> >>>> On 12/09/2016 20:53, Slawa Olhovchenkov wrote: >>>>> boot_cpu_id = 255 >>>> >>>> I think that this points towards the BIOS not configuring the BSP LAPIC >>>> correctly when you select that combination of BIOS options. >>>> That's weird, but I fail to find any other explanation. >>>> >>>> If wonder what would happen if you disable X2APIC_OPT_OUT and set >>>> hw.x2apic_enable=0 in loader.conf or at the loader prompt. >>> >>> Boot OK w/o hw.x2apic_enable=0, only with disable X2APIC_OPT_OUT. >>> >> >> This doesn't answer my question and doesn't add any new information, correct? > > I am don't see any question. I am see only suggestion of workaround. > Sorry if missunderstund. > You need some additional debug print? > I already knew from you that not enabling X2APIC_OPT_OUT fixed the problem. "If wonder what would happen if you disable X2APIC_OPT_OUT and set hw.x2apic_enable=0 in loader.conf or at the loader prompt." This was a question even though there is no question mark. -- 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"
Re: X2APIC support
On 13/09/2016 15:11, Slawa Olhovchenkov wrote: > On Tue, Sep 13, 2016 at 03:04:13PM +0300, Andriy Gapon wrote: > >> On 12/09/2016 20:53, Slawa Olhovchenkov wrote: >>> boot_cpu_id = 255 >> >> I think that this points towards the BIOS not configuring the BSP LAPIC >> correctly when you select that combination of BIOS options. >> That's weird, but I fail to find any other explanation. >> >> If wonder what would happen if you disable X2APIC_OPT_OUT and set >> hw.x2apic_enable=0 in loader.conf or at the loader prompt. > > Boot OK w/o hw.x2apic_enable=0, only with disable X2APIC_OPT_OUT. > This doesn't answer my question and doesn't add any new information, correct? -- 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"
Re: X2APIC support
On 12/09/2016 20:53, Slawa Olhovchenkov wrote: > boot_cpu_id = 255 I think that this points towards the BIOS not configuring the BSP LAPIC correctly when you select that combination of BIOS options. That's weird, but I fail to find any other explanation. If wonder what would happen if you disable X2APIC_OPT_OUT and set hw.x2apic_enable=0 in loader.conf or at the loader prompt. -- 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"
Re: X2APIC support
On 12/09/2016 19:44, Slawa Olhovchenkov wrote:
> I am not kernel developer: please point what I am need insert and file
> for edit.
In sys/amd64/amd64/mp_machdep.c (assuming you use amd64), in function
cpu_mp_start, in this place
/* Set boot_cpu_id if needed. */
if (boot_cpu_id == -1) {
boot_cpu_id = PCPU_GET(apic_id);
cpu_info[boot_cpu_id].cpu_bsp = 1;
} else
right after boot_cpu_id = PCPU_GET(apic_id) line please insert
printf("boot_cpu_id = %d\n", boot_cpu_id);
--
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"
Re: X2APIC support
On 12/09/2016 12:39, Slawa Olhovchenkov wrote:
> On Sun, Sep 04, 2016 at 08:14:07PM +0300, Andriy Gapon wrote:
>
>> On 04/09/2016 19:29, Konstantin Belousov wrote:
>>> This is possible, of course. But it would not affect "SMP: Added CPU ..."
>>> lines.
>>
>> Well, looking at the code it seems that only if mptable is used, then those
>> lines are expected to correctly identify a BSP. With MADT there is no
>> information to identify the BSP and that is supposed to happen in
>> cpu_mp_start().
>>
>>
>> static void
>> madt_add_cpu(u_int acpi_id, u_int apic_id, u_int flags)
>> {
>> struct lapic_info *la;
>>
>> /*
>> * The MADT does not include a BSP flag, so we have to let the
>> * MP code figure out which CPU is the BSP on its own.
>> */
>> ...
>>
>> In other words, those "SMP: Added CPU ..." are truly a cosmetic issue.
>> And it's my guess (just a guess) that BSP LAPIC ID is incorrect in the
>> problematic configuration.
>
> For next day or two I am have new server with same hardware before put
> in prodution.
> Can I do some test for you?
>
>From my earlier email:
"my guess can be checked by adding a printf to cpu_mp_start() right after
boot_cpu_id assignment".
--
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"
