Re: Nightly disk-related panic since upgrade to 10.3
On 10/20/16 22:12, Peter wrote: Hello. Basically You have two options: A) fire up kgdb, go into the code and try and understand what exactly is happening. This depends if You have clue enough to go that way; I found "man 4 gdb" and especially the "Debugging Kernel Problems" pdf by Greg Lehey quite helpful. I've tried this way, but altough I'm quite proficient with [k]gdb I tend to get lost in FreeBSD's kernel's source code, which, unfortunately, I'm not familiar with. BTW, I had read that book years ago; I searched for it now, but a 2005 edition still comes up. Has it ever been updated? B) systematically change parameters. Start by figuring from the logs the exact time of crash and what was happening then, try to reproduce that. Then change things and isolate the cause. Again, I already tried, but without luck. Since I had one hang one night during the creation of a snapshot, yesterday I tried creating/deleting around 40 of them: I hoped to get the system to hang again, but it all worked perfectly. Since backups are run at night (possibly at the time of the hangs/panics and doing snapshots), I launched several backup jobs, but they all worked perfectly. I checked that at the times of the panics there is usually no cron job, periodic job or whatever. At least not something I could identify. There was in fact once a periodic running, but that's not the rule. "ps -axl -M /var/crash/vmcore.x" showed nothing unusual. bye & Thanks av. ___ 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
Hi.
On 21.10.2016 9:22, Steven Hartland wrote:
On 21/10/2016 04:52, Eugene M. Zheganin wrote:
Hi.
On 20.10.2016 21:17, Steven Hartland wrote:
Do you have atime enabled for the relevant volume?
I do.
If so disable it and see if that helps:
zfs set atime=off
Nah, it doesn't help at all.
As per with Jonathon what does gstat -pd and top -SHz show?
gstat (while ls'ing):
dT: 1.005s w: 1.000s
L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps
ms/d %busy Name
1 49 49 2948 13.5 0 00.0 0 0
0.0 65.0| ada0
0 32 32 1798 11.1 0 00.0 0 0
0.0 35.3| ada1
gstat (while idling):
dT: 1.003s w: 1.000s
L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps
ms/d %busy Name
0 0 0 00.0 0 00.0 0 0
0.00.0| ada0
0 2 22550.8 0 00.0 0 0
0.00.1| ada1
top -SHz output doesn't really differ while ls'ing or idling:
last pid: 12351; load averages: 0.46, 0.49,
0.46 up 39+14:41:02 14:03:05
376 processes: 3 running, 354 sleeping, 19 waiting
CPU: 5.8% user, 0.0% nice, 16.3% system, 0.0% interrupt, 77.9% idle
Mem: 21M Active, 646M Inact, 931M Wired, 2311M Free
ARC: 73M Total, 3396K MFU, 21M MRU, 545K Anon, 1292K Header, 47M Other
Swap: 4096M Total, 4096M Free
PID USERNAME PRI NICE SIZERES STATE C TIMEWCPU COMMAND
600 root390 27564K 5072K nanslp 1 295.0H 24.56% monit
0 root -170 0K 2608K - 1 75:24 0.00%
kernel{zio_write_issue}
767 freeswitch 200 139M 31668K uwait 0 48:29 0.00%
freeswitch{freeswitch}
683 asterisk200 806M 483M uwait 0 41:09 0.00%
asterisk{asterisk}
0 root-80 0K 2608K - 0 37:43 0.00%
kernel{metaslab_group_t}
[... others lines are just 0% ...]
Thanks.
Eugene.
___
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
On 21/10/2016 10:04, Eugene M. Zheganin wrote:
Hi.
On 21.10.2016 9:22, Steven Hartland wrote:
On 21/10/2016 04:52, Eugene M. Zheganin wrote:
Hi.
On 20.10.2016 21:17, Steven Hartland wrote:
Do you have atime enabled for the relevant volume?
I do.
If so disable it and see if that helps:
zfs set atime=off
Nah, it doesn't help at all.
As per with Jonathon what does gstat -pd and top -SHz show?
gstat (while ls'ing):
dT: 1.005s w: 1.000s
L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps
ms/d %busy Name
1 49 49 2948 13.5 0 00.0 0 0 0.0
65.0| ada0
0 32 32 1798 11.1 0 00.0 0 0 0.0
35.3| ada1
Averagely busy then on rust.
gstat (while idling):
dT: 1.003s w: 1.000s
L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps
ms/d %busy Name
0 0 0 00.0 0 00.0 0 0 0.0
0.0| ada0
0 2 22550.8 0 00.0 0 0 0.0
0.1| ada1
top -SHz output doesn't really differ while ls'ing or idling:
last pid: 12351; load averages: 0.46, 0.49,
0.46 up 39+14:41:02 14:03:05
376 processes: 3 running, 354 sleeping, 19 waiting
CPU: 5.8% user, 0.0% nice, 16.3% system, 0.0% interrupt, 77.9% idle
Mem: 21M Active, 646M Inact, 931M Wired, 2311M Free
ARC: 73M Total, 3396K MFU, 21M MRU, 545K Anon, 1292K Header, 47M Other
Swap: 4096M Total, 4096M Free
PID USERNAME PRI NICE SIZERES STATE C TIMEWCPU COMMAND
600 root390 27564K 5072K nanslp 1 295.0H 24.56% monit
0 root -170 0K 2608K - 1 75:24 0.00%
kernel{zio_write_issue}
767 freeswitch 200 139M 31668K uwait 0 48:29 0.00%
freeswitch{freeswitch}
683 asterisk200 806M 483M uwait 0 41:09 0.00%
asterisk{asterisk}
0 root-80 0K 2608K - 0 37:43 0.00%
kernel{metaslab_group_t}
[... others lines are just 0% ...]
This looks like you only have ~4Gb ram which is pretty low for ZFS I
suspect vfs.zfs.prefetch_disable will be 1, which will crash the
performance.
Regards
Steve
___
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
On Fri, Oct 21, 2016 at 11:02:57AM +0100, Steven Hartland wrote:
> > Mem: 21M Active, 646M Inact, 931M Wired, 2311M Free
> > ARC: 73M Total, 3396K MFU, 21M MRU, 545K Anon, 1292K Header, 47M Other
> > Swap: 4096M Total, 4096M Free
> >
> > PID USERNAME PRI NICE SIZERES STATE C TIMEWCPU COMMAND
> > 600 root390 27564K 5072K nanslp 1 295.0H 24.56% monit
> > 0 root -170 0K 2608K - 1 75:24 0.00%
> > kernel{zio_write_issue}
> > 767 freeswitch 200 139M 31668K uwait 0 48:29 0.00%
> > freeswitch{freeswitch}
> > 683 asterisk200 806M 483M uwait 0 41:09 0.00%
> > asterisk{asterisk}
> > 0 root-80 0K 2608K - 0 37:43 0.00%
> > kernel{metaslab_group_t}
> > [... others lines are just 0% ...]
> This looks like you only have ~4Gb ram which is pretty low for ZFS I
> suspect vfs.zfs.prefetch_disable will be 1, which will crash the
> performance.
ZFS prefetch affect performance dpeneds of workload (independed of RAM
size): for some workloads wins, for some workloads lose (for my
workload prefetch is lose and manualy disabled with 128GB RAM).
Anyway, this system have only 24MB in ARC by 2.3GB free, this is may
be too low for this workload.
___
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"
Jenkins build is still unstable: FreeBSD_stable_10 #437
https://jenkins.FreeBSD.org/job/FreeBSD_stable_10/437/ ___ 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: zfs, a directory that used to hold lot of files and listing pause
Hi. On 21.10.2016 15:20, Slawa Olhovchenkov wrote: ZFS prefetch affect performance dpeneds of workload (independed of RAM size): for some workloads wins, for some workloads lose (for my workload prefetch is lose and manualy disabled with 128GB RAM). Anyway, this system have only 24MB in ARC by 2.3GB free, this is may be too low for this workload. You mean - "for getting a list of a directory with 20 subdirectories" ? Why then does only this directory have this issue with pause, not /usr/ports/..., which has more directories in it ? (and yes, /usr/ports/www isn't empty and holds 2410 entities) /usr/bin/time -h ls -1 /usr/ports/www [...] 0.14s real 0.00s user 0.00s sys Thanks. Eugene. ___ 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"
boot0cfg on does not set default selection on gmirror device
Hi, all, we are repeatedly bitten by the following misbehaviour of boot0cfg: root@hd45:/usr/local # boot0cfg -s 1 mirror/m0 root@hd45:/usr/local # boot0cfg -v mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) options=packet,update,nosetdrv default_selection=F2 (Slice 2) So, while it should have set the default to slice 1, it simply didn't. gpart on the other hand works as expected: root@hd45:/usr/local # gpart set -a active -i 1 mirror/m0 active set on mirror/m0s1 root@hd45:/usr/local # gpart show mirror/m0 =>63 1953525104 mirror/m0 MBR (932G) 63 16002 - free - (7.8M) 1606516418430 1 freebsd [active] (7.8G) 1643449516418430 2 freebsd (7.8G) 32852925 1920667140 3 freebsd (916G) 19535200655102 - free - (2.5M) But the "active" flag alone is not enough to convince boot0 to actually boot that partition. Additional info: root@hd45:/usr/local # uname -a FreeBSD hd45.hosting.punkt.de 10.3-RELEASE-p10 FreeBSD 10.3-RELEASE-p10 #0 r306942: Mon Oct 10 10:29:14 UTC 2016 root@:/usr/obj/nanobsd.hosting/usr/src/sys/GENERIC amd64 root@hd45:/usr/local # gmirror status NameStatus Components mirror/m0 COMPLETE ada0 (ACTIVE) ada1 (ACTIVE) The only way to actually switch the boot0 default selection is: root@hd45:/usr/local # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 -> 16 root@hd45:/usr/local # boot0cfg -s 1 ada0 root@hd45:/usr/local # boot0cfg -s 1 ada1 root@hd45:/usr/local # boot0cfg -v mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) options=packet,update,nosetdrv default_selection=F1 (Slice 1) Any hints what's going on, here? Obviously it is possible to manipulate the MBR of a gmirror device - as gpart proves. The boot0cfg pops up since FreeBSD 8 when we started using a mirrored NanoBSD setup. Thanks and kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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
On Fri, Oct 21, 2016 at 04:51:36PM +0500, Eugene M. Zheganin wrote: > Hi. > > On 21.10.2016 15:20, Slawa Olhovchenkov wrote: > > > > ZFS prefetch affect performance dpeneds of workload (independed of RAM > > size): for some workloads wins, for some workloads lose (for my > > workload prefetch is lose and manualy disabled with 128GB RAM). > > > > Anyway, this system have only 24MB in ARC by 2.3GB free, this is may > > be too low for this workload. > You mean - "for getting a list of a directory with 20 subdirectories" ? > Why then does only this directory have this issue with pause, not > /usr/ports/..., which has more directories in it ? > > (and yes, /usr/ports/www isn't empty and holds 2410 entities) > > /usr/bin/time -h ls -1 /usr/ports/www > [...] > 0.14s real 0.00s user 0.00s sys You wrote: "(tens of thousands) files". In bad case metadata of every file will be placed in random place of disk. ls need access to metadata of every file before start of output listing. I.e. in bad case you will be need tens of thousands seeks over disk capable only 72 seeks per seconds. Perhaps /usr/ports/www created at once and metadata of all entries placed near each other, need less seeks. If zfs property primarycache/secondarycache not off. ___ 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: Nightly disk-related panic since upgrade to 10.3
On Fri, Oct 21, 2016 at 10:14:26AM +0200, Andrea Venturoli wrote: > I've tried this way, but altough I'm quite proficient with [k]gdb I tend to > get lost in FreeBSD's kernel's source code, which, unfortunately, I'm not > familiar with. > > BTW, I had read that book years ago; I searched for it now, but a 2005 > edition still comes up. Has it ever been updated? My usual go-to documentation John Baldwin's paper: http://www.bsdcan.org/2008/schedule/attachments/45_article.pdf mcl ___ 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
> In bad case metadata of every file will be placed in random place of disk. > ls need access to metadata of every file before start of output listing. Umm, are we not talkong abut an issue where the directoyr no longer contains any files. It used to have lots, now it has none. > I.e. in bad case you will be need tens of thousands seeks over disk > capable only 72 seeks per seconds. Why does it need to seek all over the disc if there are no files (and hence no metadata surely) ? I am not bothered if a hufge directoyr takes a while to list, thats something I am happy to deal with. What I dont like is when it is back down to zero that it still takes a long time to list. That doesnt make much sense. -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs, a directory that used to hold lot of files and listing pause
On Fri, Oct 21, 2016 at 01:47:08PM +0100, Pete French wrote: > > In bad case metadata of every file will be placed in random place of disk. > > ls need access to metadata of every file before start of output listing. > > Umm, are we not talkong abut an issue where the directoyr no longer contains > any files. It used to have lots, now it has none. > > > I.e. in bad case you will be need tens of thousands seeks over disk > > capable only 72 seeks per seconds. > > Why does it need to seek all over the disc if there are no files (and hence > no metadata surely) ? > > I am not bothered if a hufge directoyr takes a while to list, > thats something I am happy to deal with. What I dont like is > when it is back down to zero that it still takes a long time > to list. That doesnt make much sense. OK, this case may be differ. May be zdb can help. ls -li /parent/dir Take inode number zdb - zfs_set inode_number also do ktrace ls and anaylyse `kdump -E` ___ 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
On Fri, 21 Oct 2016 16:51:36 +0500 "Eugene M. Zheganin" wrote: >On 21.10.2016 15:20, Slawa Olhovchenkov wrote: >> >> ZFS prefetch affect performance dpeneds of workload (independed of RAM >> size): for some workloads wins, for some workloads lose (for my >> workload prefetch is lose and manualy disabled with 128GB RAM). >> >> Anyway, this system have only 24MB in ARC by 2.3GB free, this is may >> be too low for this workload. >You mean - "for getting a list of a directory with 20 subdirectories" ? >Why then does only this directory have this issue with pause, not >/usr/ports/..., which has more directories in it ? > >(and yes, /usr/ports/www isn't empty and holds 2410 entities) > >/usr/bin/time -h ls -1 /usr/ports/www >[...] >0.14s real 0.00s user 0.00s sys > Oh, my goodness, how far afield nonsense has gotten! Have all the good folks posting in this thread forgotten how directory blocks are allocated in UNIX? This isn't even a BSD-specific thing; it's really ancient. What Eugene has complained of is exactly what is to be expected-- on really old hardware. The only eyebrow-raiser is that he has created a use case so extreme that a live human can actually notice the delays on modern hardware. I quote from his original posting: "I also have one directory that used to have a lot of (tens of thousands) files." and "But now I have 2 files and a couple of dozens directories in it". A directory with tens of thousands of files in it at one point in time most likely has somewhere well over one thousand blocks allocated. Directories don't shrink. Directory entries do not get moved around within directories when files are added or deleted. Directories can remain the same length or they can grow in length. If a directory once had many tens of thousands of filenames and links to their primary inodes, then the directory is still that big, even if it now only contains two [+ 20 to 30 directory], probably widely separated, entries. To read a file's entry, all blocks must be searched until the desired filename is found. Likewise, to list the contents of a directory, all blocks must be read until the number of files found matches the link count for the directory. IOW, if you want the performance to go back to what it was when the directory was fresh (and still small), you have to create a new directory and then move the remaining entries from the old directory into the new (small) directory. The only real difference here between UFS (or even the early AT&T filesystem) and ZFS is that the two remaining entries in a formerly huge directory are likely to be in different directory blocks that could be at effectively random locations scattered around the space of a partition for one filesystem in UFS or over an entire pool of potentially many filesystems and much more space in ZFS. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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
> Oh, my goodness, how far afield nonsense has gotten! Have all the > good folks posting in this thread forgotten how directory blocks are > allocated in UNIX? Not forgotten, just under the impression that ZFS shrinks directories unlike good old UFS. Apparenrly not, and yes, if thats true then the behaviour is not surprising in the slightest. Live and learn... ;-) -pete. [old enough to have used 32V on a Vax, a lng time ago...] ___ 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
On 2016/10/21 13:47, Pete French wrote: >> In bad case metadata of every file will be placed in random place of disk. >> ls need access to metadata of every file before start of output listing. > > Umm, are we not talkong abut an issue where the directoyr no longer contains > any files. It used to have lots, now it has none. > >> I.e. in bad case you will be need tens of thousands seeks over disk >> capable only 72 seeks per seconds. > > Why does it need to seek all over the disc if there are no files (and hence > no metadata surely) ? > > I am not bothered if a hufge directoyr takes a while to list, > thats something I am happy to deal with. What I dont like is > when it is back down to zero that it still takes a long time > to list. That doesnt make much sense. Interesting. Is this somehow related to the old Unixy thing with directories, where the directory node would grow in size as you created more and more files or sub-directories (as you might expect), but it wouldn't shrink immediately if you simply deleted many files -- it would only shrink later when you next created a new file in that directory. This was a performance feature IIRC -- it avoided shrinking and re-growing directory nodes in quick succession for what was apparently a fairly common usage pattern of clearing out a directory and then refilling it. Can't see how that would apply to ZFS though, as the CoW nature means there should be no benefit to not immediately adjusting the size of the directory node to fit the amount of contents. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: boot0cfg on does not set default selection on gmirror device
On Fri, Oct 21, 2016 at 5:39 AM, Patrick M. Hausen wrote: > Hi, all, > > we are repeatedly bitten by the following misbehaviour of boot0cfg: > > root@hd45:/usr/local # boot0cfg -s 1 mirror/m0 > root@hd45:/usr/local # boot0cfg -v mirror/m0 > # flag start chs type end chs offset size > 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 > 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 > 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 > > version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) > options=packet,update,nosetdrv > default_selection=F2 (Slice 2) > > So, while it should have set the default to slice 1, it simply didn't. > > gpart on the other hand works as expected: > > root@hd45:/usr/local # gpart set -a active -i 1 mirror/m0 > active set on mirror/m0s1 > root@hd45:/usr/local # gpart show mirror/m0 > =>63 1953525104 mirror/m0 MBR (932G) > 63 16002 - free - (7.8M) >1606516418430 1 freebsd [active] (7.8G) > 1643449516418430 2 freebsd (7.8G) > 32852925 1920667140 3 freebsd (916G) > 19535200655102 - free - (2.5M) > > But the "active" flag alone is not enough to convince boot0 to actually boot > that partition. > > Additional info: > > root@hd45:/usr/local # uname -a > FreeBSD hd45.hosting.punkt.de 10.3-RELEASE-p10 FreeBSD 10.3-RELEASE-p10 #0 > r306942: Mon Oct 10 10:29:14 UTC 2016 > root@:/usr/obj/nanobsd.hosting/usr/src/sys/GENERIC amd64 > root@hd45:/usr/local # gmirror status > NameStatus Components > mirror/m0 COMPLETE ada0 (ACTIVE) > ada1 (ACTIVE) > > > The only way to actually switch the boot0 default selection is: > > root@hd45:/usr/local # sysctl kern.geom.debugflags=16 > kern.geom.debugflags: 0 -> 16 > root@hd45:/usr/local # boot0cfg -s 1 ada0 > root@hd45:/usr/local # boot0cfg -s 1 ada1 > root@hd45:/usr/local # boot0cfg -v mirror/m0 > # flag start chs type end chs offset size > 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 > 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 > 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 > > version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) > options=packet,update,nosetdrv > default_selection=F1 (Slice 1) > > > Any hints what's going on, here? Obviously it is possible to manipulate > the MBR of a gmirror device - as gpart proves. The boot0cfg pops up > since FreeBSD 8 when we started using a mirrored NanoBSD setup. Any chance you can migrate to using gpart? Is boot0cfg still referenced in NanoBSD somewhere? Warner ___ 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: boot0cfg on does not set default selection on gmirror device
On Fri, 21 Oct 2016 13:39:57 +0200, Patrick M. Hausen wrote: > Hi, all, > > we are repeatedly bitten by the following misbehaviour of boot0cfg: > > root@hd45:/usr/local # boot0cfg -s 1 mirror/m0 > root@hd45:/usr/local # boot0cfg -v mirror/m0 > # flag start chs type end chs offset size > 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 > 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 > 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 > > version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) > options=packet,update,nosetdrv > default_selection=F2 (Slice 2) > > So, while it should have set the default to slice 1, it simply didn't. boot0cfg isn't mirror-aware as such and thinks it's using BIOS services to write to a specific drive, and likely did write to one of the disks, but it seems gmirror isn't updating both disks' MBRs - which might not be too surprising. Does it work 'sometimes'? > gpart on the other hand works as expected: > > root@hd45:/usr/local # gpart set -a active -i 1 mirror/m0 > active set on mirror/m0s1 > root@hd45:/usr/local # gpart show mirror/m0 > =>63 1953525104 mirror/m0 MBR (932G) > 63 16002 - free - (7.8M) >1606516418430 1 freebsd [active] (7.8G) > 1643449516418430 2 freebsd (7.8G) > 32852925 1920667140 3 freebsd (916G) > 19535200655102 - free - (2.5M) > > But the "active" flag alone is not enough to convince boot0 to > actually boot that partition. boot0cfg stashes -s selected nextboot slice (-1) at 0x1b5, using that to choose the default boot slice - if nothing else was selected. It doesn't set the active flag (0x80) until just before booting via BIOS, when it also updates the selection if another slice, or disk, were chosen. That is, boot0 doesn't care which active flag was set before setting it, and gpart doesn't know about non-MBR bytes in the boot sector, so can't influence boot0's behaviour. > Additional info: > > root@hd45:/usr/local # uname -a > FreeBSD hd45.hosting.punkt.de 10.3-RELEASE-p10 FreeBSD 10.3-RELEASE-p10 #0 > r306942: Mon Oct 10 10:29:14 UTC 2016 > root@:/usr/obj/nanobsd.hosting/usr/src/sys/GENERIC amd64 > root@hd45:/usr/local # gmirror status > NameStatus Components > mirror/m0 COMPLETE ada0 (ACTIVE) > ada1 (ACTIVE) > > > The only way to actually switch the boot0 default selection is: > > root@hd45:/usr/local # sysctl kern.geom.debugflags=16 > kern.geom.debugflags: 0 -> 16 > root@hd45:/usr/local # boot0cfg -s 1 ada0 > root@hd45:/usr/local # boot0cfg -s 1 ada1 > root@hd45:/usr/local # boot0cfg -v mirror/m0 > # flag start chs type end chs offset size > 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 > 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 > 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 > > version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) > options=packet,update,nosetdrv > default_selection=F1 (Slice 1) > > > Any hints what's going on, here? Obviously it is possible to manipulate > the MBR of a gmirror device - as gpart proves. The boot0cfg pops up > since FreeBSD 8 when we started using a mirrored NanoBSD setup. You might need to script the above, ie setting -s on both disks, unless someone who actually knows something about gmirror has a better clue. cheers, Ian PS sorry for busted threading, my pine had trouble quoting your message. ___ 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: boot0cfg on does not set default selection on gmirror device
Hello all, On Fri, Oct 21, 2016 at 08:41:33AM -0600, Warner Losh wrote: > On Fri, Oct 21, 2016 at 5:39 AM, Patrick M. Hausen wrote: > > Hi, all, > > > > we are repeatedly bitten by the following misbehaviour of boot0cfg: > > > > root@hd45:/usr/local # boot0cfg -s 1 mirror/m0 > > root@hd45:/usr/local # boot0cfg -v mirror/m0 > > # flag start chs type end chs offset size > > 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 > > 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 > > 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 > > > > version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) > > options=packet,update,nosetdrv > > default_selection=F2 (Slice 2) > > > > So, while it should have set the default to slice 1, it simply didn't. > > > > gpart on the other hand works as expected: > > > > root@hd45:/usr/local # gpart set -a active -i 1 mirror/m0 > > active set on mirror/m0s1 > > root@hd45:/usr/local # gpart show mirror/m0 > > =>63 1953525104 mirror/m0 MBR (932G) > > 63 16002 - free - (7.8M) > >1606516418430 1 freebsd [active] (7.8G) > > 1643449516418430 2 freebsd (7.8G) > > 32852925 1920667140 3 freebsd (916G) > > 19535200655102 - free - (2.5M) > > > > But the "active" flag alone is not enough to convince boot0 to actually > > boot that partition. > > > > Additional info: > > > > root@hd45:/usr/local # uname -a > > FreeBSD hd45.hosting.punkt.de 10.3-RELEASE-p10 FreeBSD 10.3-RELEASE-p10 #0 > > r306942: Mon Oct 10 10:29:14 UTC 2016 > > root@:/usr/obj/nanobsd.hosting/usr/src/sys/GENERIC amd64 > > root@hd45:/usr/local # gmirror status > > NameStatus Components > > mirror/m0 COMPLETE ada0 (ACTIVE) > > ada1 (ACTIVE) > > > > > > The only way to actually switch the boot0 default selection is: > > > > root@hd45:/usr/local # sysctl kern.geom.debugflags=16 > > kern.geom.debugflags: 0 -> 16 > > root@hd45:/usr/local # boot0cfg -s 1 ada0 > > root@hd45:/usr/local # boot0cfg -s 1 ada1 > > root@hd45:/usr/local # boot0cfg -v mirror/m0 > > # flag start chs type end chs offset size > > 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 > > 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 > > 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 > > > > version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) > > options=packet,update,nosetdrv > > default_selection=F1 (Slice 1) > > > > > > Any hints what's going on, here? Obviously it is possible to manipulate > > the MBR of a gmirror device - as gpart proves. The boot0cfg pops up > > since FreeBSD 8 when we started using a mirrored NanoBSD setup. > > Any chance you can migrate to using gpart? Is boot0cfg still > referenced in NanoBSD somewhere? Ahem... For what it's worth... I cannot help not pointing this old PR out: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186030 Best regards, -- rigo http://rigo.altervista.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: boot0cfg on does not set default selection on gmirror device
Ian Smith wrote on 2016/10/21 16:43: On Fri, 21 Oct 2016 13:39:57 +0200, Patrick M. Hausen wrote: > Hi, all, > > we are repeatedly bitten by the following misbehaviour of boot0cfg: > > root@hd45:/usr/local # boot0cfg -s 1 mirror/m0 > root@hd45:/usr/local # boot0cfg -v mirror/m0 > # flag start chs type end chs offset size > 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 > 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 > 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 > > version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) > options=packet,update,nosetdrv > default_selection=F2 (Slice 2) > > So, while it should have set the default to slice 1, it simply didn't. boot0cfg isn't mirror-aware as such and thinks it's using BIOS services to write to a specific drive, and likely did write to one of the disks, but it seems gmirror isn't updating both disks' MBRs - which might not be too surprising. Does it work 'sometimes'? We are using gmirror for whole drives mirroring from the time when it was introduced. It was always working with MRB/BSD. gmirror label gm0 ada0 ada1 And then you can use fdisk + bsdlabel or gpart to create slices and partitions and set it bootable on /dev/mirror/gm0. I didn't tried it with FreeBSD 10.3, but it works with 8.x (we skipped 9.x and all 8.x boxes were upgraded to 10.2 then 10.3) Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zfs, a directory that used to hold lot of files and listing pause
On Fri, Oct 21, 2016 at 10:04 AM, Pete French wrote: > Not forgotten, just under the impression that ZFS shrinks directories > unlike good old UFS. Apparenrly not, > Someone offhandedly mentioned this earlier (it's apparently intended for the future sometime). I at least hope they do something smarter than double indirect blocks these days -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ 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: boot0cfg on does not set default selection on gmirror device
Hi, all, > Am 21.10.2016 um 16:41 schrieb Warner Losh : > Any chance you can migrate to using gpart? Is boot0cfg still > referenced in NanoBSD somewhere? Not in NanoBSD but how would you configure boot0's default slice with gpart? It doesn't pay attention to the "active" flag. See Miroslav's mails for all the details. gpart would only be an option if we did not use the FreeBSD boot manager. But we need the "F1 ..., F2 ..." prompt, because being able to roll back to the last known-good system via the console is the entire point of using this NanoBSD setup. There's a presentation on the EuroBSDCon 2010 page about motivation and setup. Wonder who did that talk ... :-))) BTW: thanks, Miroslav. As for your question: it does work on the only two systems that use hardware RAID, yet have a gmirror built of only a single component to get consistent device names accross all servers. I'm not quite sure if it works from time to time, I've come to accept the "kern.geom.debugflags" dance. I had opened a similar discussion years ago for 7.x/8.x and I was told that geom was to provide an API for fdisk, boot0cfg and friends to manipulate the MBR. Because back in the days boot0cfg and fdisk both threw an error message when trying to work on a whole-disk mirror. I thought that was long solved - at least no error, anymore. But it's still not working in 10.x. Thanks to all and take care, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: boot0cfg on does not set default selection on gmirror device
On Fri, Oct 21, 2016 at 11:57 AM, Patrick M. Hausen wrote: > Hi, all, > >> Am 21.10.2016 um 16:41 schrieb Warner Losh : >> Any chance you can migrate to using gpart? Is boot0cfg still >> referenced in NanoBSD somewhere? > > Not in NanoBSD but how would you configure boot0's default > slice with gpart? It doesn't pay attention to the "active" flag. > See Miroslav's mails for all the details. > > gpart would only be an option if we did not use the FreeBSD > boot manager. Ah! OK, I thought this was the active flag issue, not the default in boot0 issue. > But we need the "F1 ..., F2 ..." prompt, because > being able to roll back to the last known-good system via the > console is the entire point of using this NanoBSD setup. > There's a presentation on the EuroBSDCon 2010 page about > motivation and setup. Wonder who did that talk ... :-))) I think I sat in the talk :) > BTW: thanks, Miroslav. As for your question: it does work on > the only two systems that use hardware RAID, yet have a > gmirror built of only a single component to get consistent > device names accross all servers. > > I'm not quite sure if it works from time to time, I've come to > accept the "kern.geom.debugflags" dance. > > I had opened a similar discussion years ago for 7.x/8.x and > I was told that geom was to provide an API for fdisk, boot0cfg > and friends to manipulate the MBR. Because back in the days > boot0cfg and fdisk both threw an error message when trying > to work on a whole-disk mirror. It certainly looks like this code has that conversion in it. Looks like it's been there quite a while. I'd have expected it to "JUST WORK" [tm]. > I thought that was long solved - at least no error, anymore. > But it's still not working in 10.x. Can you give us the strace output? It looks like it is reading the current blocks, setting the options, and then writing it back to the device. If the write back fails, it opens the device with geom and sends either the bootcode verb to geom (for the PART (aka gpart)) case or the data for the MBR case. strace should show that clearly. There's nothing in dmesg, right? Try this again but set geom.debug_flags to 128 instead of 16. This will give a verbose error in dmesg if there's any errors from the control message. Warner ___ 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: boot0cfg on does not set default selection on gmirror device
Hi, Warner, > Am 21.10.2016 um 20:25 schrieb Warner Losh : > Can you give us the strace output? amd64 - no strace. I need a hand here, what precisely do I need to enter? > It looks like it is reading the current blocks, setting the options, > and then writing it back to the device. If the write back fails, it > opens the device with geom and sends either the bootcode verb to geom > (for the PART (aka gpart)) case or the data for the MBR case. strace > should show that clearly. There's nothing in dmesg, right? Try this > again but set geom.debug_flags to 128 instead of 16. This will give a > verbose error in dmesg if there's any errors from the control message. I set the flag, then tried to change the slice from 1 to 2. Result: Dump of gctl request at 0xfe02392bd9e0: param:"class" [R5] = "PART" param:"arg0" [R10] = "mirror/m0" param:"verb" [R9] = "bootcode" param:"bootcode" [R512] = fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 07 31 d2 88 6f fc 0f a3 56 bb 73 19 8a 07 bf 87 07 b1 03 f2 ae 74 0e b1 0b f2 ae 83 c7 09 8a 0d 01 cf e8 c5 00 42 80 c3 10 73 d8 58 2c 7f 3a 06 75 04 72 05 48 74 0d 30 c0 04 b0 88 46 b8 bf b2 07 e8 a6 00 be 7b 07 e8 b2 00 8a 56 b9 4e e8 8e 00 eb 05 b0 07 e8 b0 00 30 e4 cd 1a 89 d7 03 7e bc b4 01 cd 16 75 0d 30 e4 cd 1a 39 fa 72 f2 8a 46 b9 eb 16 30 e4 cd 16 88 e0 3c 1c 74 f1 2c 3b 3c 04 76 06 2c c7 3c 04 77 c9 98 0f a3 46 0c 73 c2 88 46 b9 be 00 08 8a 14 89 f3 3c 04 9c 74 0a c0 e0 04 05 be 07 93 c6 07 80 53 f6 46 bb 40 75 08 bb 00 06 b4 03 e8 59 00 5e 9d 75 06 8a 56 b8 80 ea 30 bb 00 7c b4 02 e8 47 00 72 86 81 bf fe 01 55 aa 0f 85 7c ff be 85 07 e8 19 00 ff e3 b0 46 e8 24 00 b0 31 00 d0 eb 17 0f ab 56 0c be 78 07 e8 eb ff 89 fe e8 03 00 be 85 07 ac a8 80 75 05 e8 04 00 eb f6 24 7f 53 bb 07 00 b4 0e cd 10 5b c3 8a 74 01 8b 4c 02 b0 01 56 89 e7 f6 46 bb 80 74 13 66 6a 00 66 ff 74 08 06 53 6a 01 6a 10 89 e6 48 80 cc 40 cd 13 89 fc 5e c3 20 20 a0 0a 44 65 66 61 75 6c 74 3a a0 0d 8a 00 05 0f 01 06 07 0b 0c 0e 83 a5 a6 a9 0d 0c 0b 0a 09 08 0a 0e 11 10 01 3f bf 44 4f d3 4c 69 6e 75 f8 46 72 65 65 42 53 c4 66 bb 44 72 69 76 65 20 b1 01 80 8f b6 00 80 00 01 01 a5 fe ff fe c1 3e 00 00 7e 86 fa 00 00 00 c1 ff a5 fe ff fc 3f c5 fa 00 7e 86 fa 00 00 00 c1 fd a5 fe ff 00 bd 4b f5 01 04 0e 7b 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa param:"flags" [R2] = "C" root@hd45:~ # boot0cfg -v mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) options=packet,update,nosetdrv default_selection=F1 (Slice 1) So again, no change. Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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"
panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE
Hi, friendly community. I present to you my collection. I have : //===// System Information Manufacturer: Supermicro Product Name: X10SLH-F/X10SLM+-F //===// pciconf -lv hostb0@pci0:0:0:0: class=0x06 card=0x080315d9 chip=0x0c088086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon E3-1200 v3 Processor DRAM Controller' class = bridge subclass = HOST-PCI xhci0@pci0:0:20:0: class=0x0c0330 card=0x080315d9 chip=0x8c318086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family USB xHCI' class = serial bus subclass = USB none0@pci0:0:22:0: class=0x078000 card=0x080315d9 chip=0x8c3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family MEI Controller' class = simple comms none1@pci0:0:22:1: class=0x078000 card=0x080315d9 chip=0x8c3b8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family MEI Controller' class = simple comms ehci0@pci0:0:26:0: class=0x0c0320 card=0x080315d9 chip=0x8c2d8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family USB EHCI' class = serial bus subclass = USB pcib1@pci0:0:28:0: class=0x060400 card=0x080315d9 chip=0x8c108086 rev=0xd5 hdr=0x01 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family PCI Express Root Port' class = bridge subclass = PCI-PCI pcib3@pci0:0:28:2: class=0x060400 card=0x080315d9 chip=0x8c148086 rev=0xd5 hdr=0x01 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family PCI Express Root Port' class = bridge subclass = PCI-PCI pcib4@pci0:0:28:3: class=0x060400 card=0x080315d9 chip=0x8c168086 rev=0xd5 hdr=0x01 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family PCI Express Root Port' class = bridge subclass = PCI-PCI ehci1@pci0:0:29:0: class=0x0c0320 card=0x080315d9 chip=0x8c268086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family USB EHCI' class = serial bus subclass = USB isab0@pci0:0:31:0: class=0x060100 card=0x080315d9 chip=0x8c548086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'C224 Series Chipset Family Server Standard SKU LPC Controller' class = bridge subclass = PCI-ISA ahci0@pci0:0:31:2: class=0x010601 card=0x080315d9 chip=0x8c028086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode]' class = mass storage subclass = SATA ichsmb0@pci0:0:31:3:class=0x0c0500 card=0x080315d9 chip=0x8c228086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series/C220 Series Chipset Family SMBus Controller' class = serial bus subclass = SMBus none2@pci0:0:31:6: class=0x118000 card=0x080315d9 chip=0x8c248086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '8 Series Chipset Family Thermal Management Controller' class = dasp pcib2@pci0:1:0:0: class=0x060400 card=0x080315d9 chip=0x11501a03 rev=0x03 hdr=0x01 vendor = 'ASPEED Technology, Inc.' device = 'AST1150 PCI-to-PCI Bridge' class = bridge subclass = PCI-PCI vgapci0@pci0:2:0:0: class=0x03 card=0x080315d9 chip=0x20001a03 rev=0x30 hdr=0x00 vendor = 'ASPEED Technology, Inc.' device = 'ASPEED Graphics Family' class = display subclass = VGA igb0@pci0:3:0:0:class=0x02 card=0x153315d9 chip=0x15338086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet igb1@pci0:4:0:0:class=0x02 card=0x153315d9 chip=0x15338086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet //===// In fact, a collection of panics: //===// Sep 15 11:57:22 ns kernel: Fatal trap 12: page fault while in kernel mode Sep 15 11:57:22 ns kernel: cpuid = 6; apic id = 06 Sep 15 11:57:22 ns kernel: fault virtual address = 0x8 Sep 15 11:57:22 ns kernel: fault code = supervisor read data, page not present Sep 15 11:57:22 ns kernel: instruction pointer= 0x20:0x80baca70 Sep 15 11:57:22 ns kernel: stack pointer = 0x28:0xfe07c9eba540 Sep 15 11:57:22 ns kernel: frame pointer = 0x28:0xfe07c9eba580 Sep 15 11:57:22 ns kernel: code segment = base 0x0, limit 0xf, t
Re: panics collections on FreeBSD 11.0-RC1 RC2 PRERELEASE RELEASE STABLE
Next Oct 21 22:06:26 ns syslogd: kernel boot file is /boot/kernel/kernel Oct 21 22:06:26 ns kernel: panic: sbsndptr: sockbuf 0xf80201038518 and mbuf 0xf802820a1200 clashing Oct 21 22:06:26 ns kernel: cpuid = 3 Oct 21 22:06:26 ns kernel: KDB: stack backtrace: Oct 21 22:06:26 ns kernel: #0 0x80b5f0e7 at kdb_backtrace+0x67 Oct 21 22:06:26 ns kernel: #1 0x80b129c2 at vpanic+0x182 Oct 21 22:06:26 ns kernel: #2 0x80b12833 at panic+0x43 Oct 21 22:06:26 ns kernel: #3 0x80bafc4a at sbsndptr+0xda Oct 21 22:06:26 ns kernel: #4 0x80d57b88 at tcp_output+0x1168 Oct 21 22:06:26 ns kernel: #5 0x80d540f6 at tcp_do_segment+0x30d6 Oct 21 22:06:26 ns kernel: #6 0x80d508b6 at tcp_input+0x14a6 Oct 21 22:06:26 ns kernel: #7 0x80cb54be at ip_input+0x18e Oct 21 22:06:26 ns kernel: #8 0x80c49add at netisr_dispatch_src+0xad Oct 21 22:06:26 ns kernel: #9 0x80c3815e at tunwrite+0x2ee Oct 21 22:06:26 ns kernel: #10 0x809b54e7 at devfs_write_f+0xe7 Oct 21 22:06:26 ns kernel: #11 0x80b7e227 at dofilewrite+0x87 Oct 21 22:06:26 ns kernel: #12 0x80b7ddf9 at sys_write+0xd9 Oct 21 22:06:26 ns kernel: #13 0x8105ac2e at amd64_syscall+0x51e Oct 21 22:06:26 ns kernel: #14 0x8103bbcb at Xfast_syscall+0xfb Oct 21 22:06:26 ns kernel: Uptime: 37m25s Oct 21 22:06:26 ns kernel: Dumping 1500 out of 32688 MB:..2%..11%..21%..31%..41%..51%..61%..71%..82%..91% ___ 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: boot0cfg on does not set default selection on gmirror device
On Fri, 21 Oct 2016 20:47:20 +0200, Patrick M. Hausen wrote: Again, trouble quoting your message properly, so quotes by hand .. > I set the flag, then tried to change the slice from 1 to 2. > Result: [..] > root@hd45:~ # boot0cfg -v mirror/m0 > # flag start chs type end chs offset size > 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 > 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 > 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 > > version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) > options=packet,update,nosetdrv > default_selection=F1 (Slice 1) > > So again, no change. In my previous message I said that the boot selection would be stored in 0x1b5. That was ASSuming we'd be looking at a version=2.0 boot0, which from the above is not the case. For version=1.0 that byte is at 0x1b9. Discombobulating the dump: 0x1b0: 66 bb 44 72 69 76 65 20 b1 01 80 8f b6 00 80 00 v2 v1 ^active 0x1c0: 01 01 a5 fe ff fe c1 3e 00 00 7e 86 fa 00 00 00 0x1d0: c1 ff a5 fe ff fc 3f c5 fa 00 7e 86 fa 00 00 00 0x1e0: c1 fd a5 fe ff 00 bd 4b f5 01 04 0e 7b 72 00 00 0x1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa So 0x1b9 = 1, +1 = 2 (for F2). It appears correct in the dump but not in what boot0cfg then reports. I wonder two things: Do 'boot0cfg -v ada0' and 'boot0cfg -v ada1' both report the same? Might it work properly if you upgraded the boot sectors to version 2, which is what you should get if you reinstall from current boot0cfg, presumably without touching the MBR data, but you'll have backups .. Only noticing because I made a memstick with boot0 the other day from FreeBSD 9.3 and it showed version=2.0 with a (dummy) volume serial ID, the same time as finding that setting active with gpart had no effect. cheers, ian ___ 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"
moused(?) touchpad issue after updating to FreeBSD 11.0-STABLE #0 r307755 amd64
Namely, the touchpad ceased to simulate mouse buttons (doesn't respond to tapping). Any pointers? It must be recent, source from few days ago worked ok. -- View this message in context: http://freebsd.1045724.x6.nabble.com/moused-touchpad-issue-after-updating-to-FreeBSD-11-0-STABLE-0-r307755-amd64-tp6138663.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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: moused(?) touchpad issue after updating to FreeBSD 11.0-STABLE #0 r307755 amd64
I'm going afk for a couple days, all I've got so far from moused is- /dev/psm0 ps/2 sysmouse generic moused: proto params: f8 80 00 00 8 00 ff The laptop in question is Thinkpad T400. -- View this message in context: http://freebsd.1045724.x6.nabble.com/moused-touchpad-issue-after-updating-to-FreeBSD-11-0-STABLE-0-r307755-amd64-tp6138663p6138664.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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"
