Re: Running FreeBSD on M.2 SSD
Hello, I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to test) and on my Hybrid HDD. Just configured and rc.conf to start my wifi dongle, downoaded git, node and npm via pkg and... as you can see in my screenshot, the ZFS already shows corrupted data... Can't been able to load the FreeBSD from the HDD though, don't know why, if someone direct me how to load the kernel from the HDD via loader or grub2, I'll try =) Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo escreveu: > Hello, > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to > test) and on my Hybrid HDD. > > Just configured and rc.conf to start my wifi dongle, downoaded git, node > and npm via pkg and... as you can see in my screenshot, > the ZFS already shows corrupted data... > > Can't been able to load the FreeBSD from the HDD though, don't know why, > if someone direct me how to load the > kernel from the HDD via loader or grub2, I'll try =) > > Mario > > Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger > escreveu: > >> >> On 2/25/2020 9:53 AM, John Kennedy wrote: >> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: >> >> I have often wondered if ZFS is more aggressive with discs, because >> until >> >> very recently any solid state drive I have used ZFS on broke very >> quicky. ... >> >I've always wondered if ZFS (and other snapshotting file systems) >> would help >> > kill SSD disks by locking up blocks longer than other filesystems >> might. For >> > example, I've got snapshot-backups going back, say, a year then those >> blocks >> > that haven't changed aren't going back into the pool to be rewritten >> (and >> > perhaps favored because of low write-cycle count). As the disk fills >> up, the >> > blocks that aren't locked up get reused more and more, leading to extra >> wear >> > on them. Eventually one of those will get to the point of erroring out. >> > >> >Personally, I just size generously but that isn't always an option >> for >> > everybody. >> >> I have a ZFS RaidZ2 on SSDs that has been running for several /years >> /without any problems. The drives are Intel 730s, which Intel CLAIMS >> don't have power-loss protection but in fact appear to; not only do they >> have caps in them but in addition they pass a "pull the cord out of the >> wall and then check to see if the data is corrupted on restart" test on >> a repeated basis, which I did several times before trusting them. >> >> BTW essentially all non-data-center SSDs fail that test and some fail it >> spectacularly (destroying the OS due to some of the in-flight data being >> comingled on an allocated block with something important; if the >> read/erase/write cycle interrupts you're cooked as the "other" data that >> was not being modified gets destroyed too!) -- the Intels are one of the >> very, very few that have passed it. >> >> -- >> -- Karl Denninger >> /The Market-Ticker/ >> S/MIME Email accepted and preferred >> > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
Hello, I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to test) and on my Hybrid HDD. Just configured and rc.conf to start my wifi dongle, downoaded git, node and npm via pkg and... as you can see in my screenshot, the ZFS already shows corrupted data... Can't been able to load the FreeBSD from the HDD though, don't know why, if someone direct me how to load the kernel from the HDD via loader or grub2, I'll try =) Mario Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger escreveu: > > On 2/25/2020 9:53 AM, John Kennedy wrote: > > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: > >> I have often wondered if ZFS is more aggressive with discs, because > until > >> very recently any solid state drive I have used ZFS on broke very > quicky. ... > >I've always wondered if ZFS (and other snapshotting file systems) > would help > > kill SSD disks by locking up blocks longer than other filesystems > might. For > > example, I've got snapshot-backups going back, say, a year then those > blocks > > that haven't changed aren't going back into the pool to be rewritten (and > > perhaps favored because of low write-cycle count). As the disk fills > up, the > > blocks that aren't locked up get reused more and more, leading to extra > wear > > on them. Eventually one of those will get to the point of erroring out. > > > >Personally, I just size generously but that isn't always an option for > > everybody. > > I have a ZFS RaidZ2 on SSDs that has been running for several /years > /without any problems. The drives are Intel 730s, which Intel CLAIMS > don't have power-loss protection but in fact appear to; not only do they > have caps in them but in addition they pass a "pull the cord out of the > wall and then check to see if the data is corrupted on restart" test on > a repeated basis, which I did several times before trusting them. > > BTW essentially all non-data-center SSDs fail that test and some fail it > spectacularly (destroying the OS due to some of the in-flight data being > comingled on an allocated block with something important; if the > read/erase/write cycle interrupts you're cooked as the "other" data that > was not being modified gets destroyed too!) -- the Intels are one of the > very, very few that have passed it. > > -- > -- Karl Denninger > /The Market-Ticker/ > S/MIME Email accepted and preferred > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ntp problems stratum 2 to 14?
I usually run ntpd with both aslr and as user ntpd. While testing I
noticed that my server with a direct network cable to my main time keeper,
jumped from the expected stratum 2 to 14 as follows (I record the date so I
can synch with the debug log, also below):
vm.loadavg={ 0.09 0.10 0.18 }
Wed 26 Feb 2020 15:16:38 AEDT
remote refid st t when poll reach delay offset
jitter
==
10.0.7.6203.35.83.2422 u 44 64 3770.147 -227.12
33.560
*127.127.1.1 .LOCL. 14 l 59 128 3770.0000.000
0.000
Wed 26 Feb 2020 15:18:46 AEDT
remote refid st t when poll reach delay offset
jitter
==
10.0.7.6LOCAL(1)14 u 42 64 3770.147 -227.12
44.529
*127.127.1.1 .LOCL. 14 l 59 128 3770.0000.000
0.000
Wed 26 Feb 2020 15:20:54 AEDT
remote refid st t when poll reach delay offset
jitter
==
10.0.7.6LOCAL(1)14 u 42 64 3770.147 -227.12
73.969
*127.127.1.1 .LOCL. 14 l 59 128 3770.0000.000
0.000
Wed 26 Feb 2020 15:23:02 AEDT
remote refid st t when poll reach delay offset
jitter
==
*10.0.7.6LOCAL(1)14 u 37 64 3770.164 -370.64
74.119
127.127.1.1 .LOCL. 14 l 59 128 3770.0000.000
0.000
Time marches on
Wed 26 Feb 2020 16:03:35 AEDT
remote refid st t when poll reach delay offset
jitter
==
*10.0.7.6LOCAL(1)14 u 11 64 1770.133 -3.148
72.295
127.127.1.1 .LOCL. 14 l 406 128 100.0000.000
0.000
Wed 26 Feb 2020 16:05:43 AEDT
remote refid st t when poll reach delay offset
jitter
==
*10.0.7.6203.35.83.2422 u7 64 3770.164 -42.789
73.762
127.127.1.1 .LOCL. 14 l 534 128 200.0000.000
0.000
The debug for the above is:
26 Feb 14:58:33 ntpd[8772]: Command line: /usr/local/sbin/ntpd -c
/etc/ntp.conf -g -g -u ntpd --nofork
...
26 Feb 14:58:34 ntpd[8772]: 10.0.7.6 e014 84 reachable
26 Feb 14:58:35 ntpd[8772]: LOCAL(1) 8014 84 reachable
26 Feb 15:03:40 ntpd[8772]: LOCAL(1) 901a 8a sys_peer <== bad
26 Feb 15:03:40 ntpd[8772]: 0.0.0.0 c515 05 clock_sync
26 Feb 15:22:25 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer <=== Good!
26 Feb 15:22:25 ntpd[8772]: 0.0.0.0 0613 03 spike_detect -0.370644 s
26 Feb 15:30:03 ntpd[8772]: 0.0.0.0 061c 0c clock_step -0.536289 s
26 Feb 15:30:02 ntpd[8772]: 0.0.0.0 0615 05 clock_sync
26 Feb 15:30:03 ntpd[8772]: 0.0.0.0 c618 08 no_sys_peer
26 Feb 15:30:03 ntpd[8772]: 10.0.7.6 e014 84 reachable
26 Feb 15:30:07 ntpd[8772]: LOCAL(1) 8014 84 reachable
26 Feb 15:30:21 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer
...
26 Feb 15:46:49 ntpd[8772]: 0.0.0.0 c618 08 no_sys_peer
26 Feb 15:46:57 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer
...
26 Feb 15:56:58 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer
...
26 Feb 16:24:33 ntpd[8772]: LOCAL(1) 901a 8a sys_peer <== and stays LOCAL
which is now normal for this box :(
Should the jump to stratum 14 be expected? Anything obviously wrong with
the ntp.conf?
I've had a few days of testing on what is usually a very stable (time-wise
system), seems that running at prio 20 is required.
/etc/ntp.conf contains
rlimit memlock -1
rlimit filenum 32
driftfile /var/db/ntp/drift
disable bclient
server 10.0.7.6 iburst minpoll 4 maxpoll 6 version 4 key 23057 prefer
server 127.127.1.1 minpoll 7 maxpoll 7
fudge 127.127.1.1 stratum 14
restrict -4 default ignore
restrict -6 default ignore
restrict 127.0.0.1 nomodify nopeer notrap
restrict -6 ::1 nomodify nopeer notrap
restrict 0.0.0.0 ignore
restrict 10.0.7.6 nomodify nopeer noquery notrap ntpport
restrict 10.169.168.91 mask 255.255.255.0 nomodify nopeer noquery notrap
ntpport kod limited
I'm also very surprised that the jitter on the server (under testing) is so
poor. The internet facing time server is
*x.y.z.t .ATOM. 1 u 73 5127 23.776 34.905 95.961
but its very old and not running aslr.
Any ideas or pointers would be appreciated. This is very, time consuming.
:)
I'm using the following command sequence as these are all being changed
sysctl kern.elf64.aslr.enable=1 kern.elf64.aslr.stack_gap=1
security.mac.ntpd.enabled=1 && \
/usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpdate -v -a
23057 -k /etc/ntp.keys 10.0.7.6 && sleep 2 && \
/rescue/nice -n -20 /usr/bin/proccontrol -m aslr -s disable
/usr/local/sbin/ntpd -c /etc/ntp.conf -g -g -u ntpd --nofork
Re: Running FreeBSD on M.2 SSD
Guys, just a little update: I was able to boot from the HDD, just had to remove the FreeBSD partition from the SSD because the loader always load from the first pool that it founds (I say first because the two installations was on zfs/root, so it never boot the second pool). After one hour of usage the ZFS remains stable, no errors detected. I installed git, npm, node, xorg, xfce4, put some projects and loaded all the node_modules dependencies and after some time deleted some files, reboot twice, add and remove more files and the system have 0 errors... The problem with it on the SSD maybe really related to some lack of a very specific configuration of my part or is a driver parameter/misdetection problem =/ If you need more information from the system I can collect! Thank you all for the support, Mario Em ter., 25 de fev. de 2020 às 21:26, Mario Olofo escreveu: > Hybrid HDD are the norm for notebooks, that is, 1TB hard drive with 16GB > of SSD internal memory for fast writes and hot data (most used pages). > In my case, the notebook came with a ST1000LX015, but the problem happened > on the SSD, not on this HDD. > The SSD is a WD Green m.2, Rebecca already posted a link to the model: > https://shop.westerndigital.com/products/internal-drives/wd-green-sata-ssd#WDS480G2G0B > > Mario > > Em ter., 25 de fev. de 2020 às 21:12, George Michaelson > escreveu: > >> you said "hybrid HDD" >> >> is this possibly about write-back vs write-through cache integrity and >> some confusion in a driver over what is committed back in disk, and >> what is not? >> >> this feels like a very nasty corner case. Could you be explicit about >> versions and vendors? >> >> I am asking for selfish reasons: I have a lot of dependencies in a >> large SSD backed ZFS postgres server on Dell, and I am about to commit >> to a lenovo X1 Carbon 7/8th gen which would be SSD and almost >> certainly was intended to be ZFS-SSD in FreeBSD. >> >> -George >> >> On Wed, Feb 26, 2020 at 9:22 AM Mario Olofo >> wrote: >> > >> > Hello, >> > >> > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux >> to >> > test) and on my Hybrid HDD. >> > >> > Just configured rc.conf to start my wifi dongle, downoaded git, node and >> > npm via pkg and... as you can see in my screenshot, >> > the ZFS already shows corrupted data... >> > >> > Can't been able to load the FreeBSD from the HDD though, don't know >> why, if >> > someone knows how to load the >> > kernel from the HDD via loader on SSD or grub2, I can try =) >> > >> > Mario >> > >> > Em ter., 25 de fev. de 2020 às 20:18, Mario Olofo < >> mario.ol...@gmail.com> >> > escreveu: >> > >> > > Hello, >> > > >> > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my >> Linux to >> > > test) and on my Hybrid HDD. >> > > >> > > Just configured and rc.conf to start my wifi dongle, downoaded git, >> node >> > > and npm via pkg and... as you can see in my screenshot, >> > > the ZFS already shows corrupted data... >> > > >> > > Can't been able to load the FreeBSD from the HDD though, don't know >> why, >> > > if someone direct me how to load the >> > > kernel from the HDD via loader or grub2, I'll try =) >> > > >> > > Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo < >> mario.ol...@gmail.com> >> > > escreveu: >> > > >> > >> Hello, >> > >> >> > >> I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my >> Linux >> > >> to test) and on my Hybrid HDD. >> > >> >> > >> Just configured and rc.conf to start my wifi dongle, downoaded git, >> node >> > >> and npm via pkg and... as you can see in my screenshot, >> > >> the ZFS already shows corrupted data... >> > >> >> > >> Can't been able to load the FreeBSD from the HDD though, don't know >> why, >> > >> if someone direct me how to load the >> > >> kernel from the HDD via loader or grub2, I'll try =) >> > >> >> > >> Mario >> > >> >> > >> Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger < >> k...@denninger.net> >> > >> escreveu: >> > >> >> > >>> >> > >>> On 2/25/2020 9:53 AM, John Kennedy wrote: >> > >>> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: >> > >>> >> I have often wondered if ZFS is more aggressive with discs, >> because >> > >>> until >> > >>> >> very recently any solid state drive I have used ZFS on broke very >> > >>> quicky. ... >> > >>> >I've always wondered if ZFS (and other snapshotting file >> systems) >> > >>> would help >> > >>> > kill SSD disks by locking up blocks longer than other filesystems >> > >>> might. For >> > >>> > example, I've got snapshot-backups going back, say, a year then >> those >> > >>> blocks >> > >>> > that haven't changed aren't going back into the pool to be >> rewritten >> > >>> (and >> > >>> > perhaps favored because of low write-cycle count). As the disk >> fills >> > >>> up, the >> > >>> > blocks that aren't locked up get reused more and more, leading to >> > >>> extra wear >> > >>> > on them. Eventually one of those will get to the point of >> erroring
Re: Running FreeBSD on M.2 SSD
Hybrid HDD are the norm for notebooks, that is, 1TB hard drive with 16GB of SSD internal memory for fast writes and hot data (most used pages). In my case, the notebook came with a ST1000LX015, but the problem happened on the SSD, not on this HDD. The SSD is a WD Green m.2, Rebecca already posted a link to the model: https://shop.westerndigital.com/products/internal-drives/wd-green-sata-ssd#WDS480G2G0B Mario Em ter., 25 de fev. de 2020 às 21:12, George Michaelson escreveu: > you said "hybrid HDD" > > is this possibly about write-back vs write-through cache integrity and > some confusion in a driver over what is committed back in disk, and > what is not? > > this feels like a very nasty corner case. Could you be explicit about > versions and vendors? > > I am asking for selfish reasons: I have a lot of dependencies in a > large SSD backed ZFS postgres server on Dell, and I am about to commit > to a lenovo X1 Carbon 7/8th gen which would be SSD and almost > certainly was intended to be ZFS-SSD in FreeBSD. > > -George > > On Wed, Feb 26, 2020 at 9:22 AM Mario Olofo wrote: > > > > Hello, > > > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux > to > > test) and on my Hybrid HDD. > > > > Just configured rc.conf to start my wifi dongle, downoaded git, node and > > npm via pkg and... as you can see in my screenshot, > > the ZFS already shows corrupted data... > > > > Can't been able to load the FreeBSD from the HDD though, don't know why, > if > > someone knows how to load the > > kernel from the HDD via loader on SSD or grub2, I can try =) > > > > Mario > > > > Em ter., 25 de fev. de 2020 às 20:18, Mario Olofo > > > escreveu: > > > > > Hello, > > > > > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my > Linux to > > > test) and on my Hybrid HDD. > > > > > > Just configured and rc.conf to start my wifi dongle, downoaded git, > node > > > and npm via pkg and... as you can see in my screenshot, > > > the ZFS already shows corrupted data... > > > > > > Can't been able to load the FreeBSD from the HDD though, don't know > why, > > > if someone direct me how to load the > > > kernel from the HDD via loader or grub2, I'll try =) > > > > > > Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo < > mario.ol...@gmail.com> > > > escreveu: > > > > > >> Hello, > > >> > > >> I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my > Linux > > >> to test) and on my Hybrid HDD. > > >> > > >> Just configured and rc.conf to start my wifi dongle, downoaded git, > node > > >> and npm via pkg and... as you can see in my screenshot, > > >> the ZFS already shows corrupted data... > > >> > > >> Can't been able to load the FreeBSD from the HDD though, don't know > why, > > >> if someone direct me how to load the > > >> kernel from the HDD via loader or grub2, I'll try =) > > >> > > >> Mario > > >> > > >> Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger < > k...@denninger.net> > > >> escreveu: > > >> > > >>> > > >>> On 2/25/2020 9:53 AM, John Kennedy wrote: > > >>> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: > > >>> >> I have often wondered if ZFS is more aggressive with discs, > because > > >>> until > > >>> >> very recently any solid state drive I have used ZFS on broke very > > >>> quicky. ... > > >>> >I've always wondered if ZFS (and other snapshotting file > systems) > > >>> would help > > >>> > kill SSD disks by locking up blocks longer than other filesystems > > >>> might. For > > >>> > example, I've got snapshot-backups going back, say, a year then > those > > >>> blocks > > >>> > that haven't changed aren't going back into the pool to be > rewritten > > >>> (and > > >>> > perhaps favored because of low write-cycle count). As the disk > fills > > >>> up, the > > >>> > blocks that aren't locked up get reused more and more, leading to > > >>> extra wear > > >>> > on them. Eventually one of those will get to the point of erroring > > >>> out. > > >>> > > > >>> >Personally, I just size generously but that isn't always an > option > > >>> for > > >>> > everybody. > > >>> > > >>> I have a ZFS RaidZ2 on SSDs that has been running for several /years > > >>> /without any problems. The drives are Intel 730s, which Intel CLAIMS > > >>> don't have power-loss protection but in fact appear to; not only do > they > > >>> have caps in them but in addition they pass a "pull the cord out of > the > > >>> wall and then check to see if the data is corrupted on restart" test > on > > >>> a repeated basis, which I did several times before trusting them. > > >>> > > >>> BTW essentially all non-data-center SSDs fail that test and some > fail it > > >>> spectacularly (destroying the OS due to some of the in-flight data > being > > >>> comingled on an allocated block with something important; if the > > >>> read/erase/write cycle interrupts you're cooked as the "other" data > that > > >>> was not being modified gets destroyed too!) -- the Intels are one of > the > > >
Re: Running FreeBSD on M.2 SSD
you said "hybrid HDD" is this possibly about write-back vs write-through cache integrity and some confusion in a driver over what is committed back in disk, and what is not? this feels like a very nasty corner case. Could you be explicit about versions and vendors? I am asking for selfish reasons: I have a lot of dependencies in a large SSD backed ZFS postgres server on Dell, and I am about to commit to a lenovo X1 Carbon 7/8th gen which would be SSD and almost certainly was intended to be ZFS-SSD in FreeBSD. -George On Wed, Feb 26, 2020 at 9:22 AM Mario Olofo wrote: > > Hello, > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to > test) and on my Hybrid HDD. > > Just configured rc.conf to start my wifi dongle, downoaded git, node and > npm via pkg and... as you can see in my screenshot, > the ZFS already shows corrupted data... > > Can't been able to load the FreeBSD from the HDD though, don't know why, if > someone knows how to load the > kernel from the HDD via loader on SSD or grub2, I can try =) > > Mario > > Em ter., 25 de fev. de 2020 às 20:18, Mario Olofo > escreveu: > > > Hello, > > > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to > > test) and on my Hybrid HDD. > > > > Just configured and rc.conf to start my wifi dongle, downoaded git, node > > and npm via pkg and... as you can see in my screenshot, > > the ZFS already shows corrupted data... > > > > Can't been able to load the FreeBSD from the HDD though, don't know why, > > if someone direct me how to load the > > kernel from the HDD via loader or grub2, I'll try =) > > > > Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo > > escreveu: > > > >> Hello, > >> > >> I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux > >> to test) and on my Hybrid HDD. > >> > >> Just configured and rc.conf to start my wifi dongle, downoaded git, node > >> and npm via pkg and... as you can see in my screenshot, > >> the ZFS already shows corrupted data... > >> > >> Can't been able to load the FreeBSD from the HDD though, don't know why, > >> if someone direct me how to load the > >> kernel from the HDD via loader or grub2, I'll try =) > >> > >> Mario > >> > >> Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger > >> escreveu: > >> > >>> > >>> On 2/25/2020 9:53 AM, John Kennedy wrote: > >>> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: > >>> >> I have often wondered if ZFS is more aggressive with discs, because > >>> until > >>> >> very recently any solid state drive I have used ZFS on broke very > >>> quicky. ... > >>> >I've always wondered if ZFS (and other snapshotting file systems) > >>> would help > >>> > kill SSD disks by locking up blocks longer than other filesystems > >>> might. For > >>> > example, I've got snapshot-backups going back, say, a year then those > >>> blocks > >>> > that haven't changed aren't going back into the pool to be rewritten > >>> (and > >>> > perhaps favored because of low write-cycle count). As the disk fills > >>> up, the > >>> > blocks that aren't locked up get reused more and more, leading to > >>> extra wear > >>> > on them. Eventually one of those will get to the point of erroring > >>> out. > >>> > > >>> >Personally, I just size generously but that isn't always an option > >>> for > >>> > everybody. > >>> > >>> I have a ZFS RaidZ2 on SSDs that has been running for several /years > >>> /without any problems. The drives are Intel 730s, which Intel CLAIMS > >>> don't have power-loss protection but in fact appear to; not only do they > >>> have caps in them but in addition they pass a "pull the cord out of the > >>> wall and then check to see if the data is corrupted on restart" test on > >>> a repeated basis, which I did several times before trusting them. > >>> > >>> BTW essentially all non-data-center SSDs fail that test and some fail it > >>> spectacularly (destroying the OS due to some of the in-flight data being > >>> comingled on an allocated block with something important; if the > >>> read/erase/write cycle interrupts you're cooked as the "other" data that > >>> was not being modified gets destroyed too!) -- the Intels are one of the > >>> very, very few that have passed it. > >>> > >>> -- > >>> -- Karl Denninger > >>> /The Market-Ticker/ > >>> S/MIME Email accepted and preferred > >>> > >> > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ 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: Running FreeBSD on M.2 SSD
Hello, I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to test) and on my Hybrid HDD. Just configured rc.conf to start my wifi dongle, downoaded git, node and npm via pkg and... as you can see in my screenshot, the ZFS already shows corrupted data... Can't been able to load the FreeBSD from the HDD though, don't know why, if someone knows how to load the kernel from the HDD via loader on SSD or grub2, I can try =) Mario Em ter., 25 de fev. de 2020 às 20:18, Mario Olofo escreveu: > Hello, > > I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux to > test) and on my Hybrid HDD. > > Just configured and rc.conf to start my wifi dongle, downoaded git, node > and npm via pkg and... as you can see in my screenshot, > the ZFS already shows corrupted data... > > Can't been able to load the FreeBSD from the HDD though, don't know why, > if someone direct me how to load the > kernel from the HDD via loader or grub2, I'll try =) > > Em ter., 25 de fev. de 2020 às 18:56, Mario Olofo > escreveu: > >> Hello, >> >> I reinstalled FreeBSD 12.1 on my SSD (in the swap partition of my Linux >> to test) and on my Hybrid HDD. >> >> Just configured and rc.conf to start my wifi dongle, downoaded git, node >> and npm via pkg and... as you can see in my screenshot, >> the ZFS already shows corrupted data... >> >> Can't been able to load the FreeBSD from the HDD though, don't know why, >> if someone direct me how to load the >> kernel from the HDD via loader or grub2, I'll try =) >> >> Mario >> >> Em ter., 25 de fev. de 2020 às 12:11, Karl Denninger >> escreveu: >> >>> >>> On 2/25/2020 9:53 AM, John Kennedy wrote: >>> > On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: >>> >> I have often wondered if ZFS is more aggressive with discs, because >>> until >>> >> very recently any solid state drive I have used ZFS on broke very >>> quicky. ... >>> >I've always wondered if ZFS (and other snapshotting file systems) >>> would help >>> > kill SSD disks by locking up blocks longer than other filesystems >>> might. For >>> > example, I've got snapshot-backups going back, say, a year then those >>> blocks >>> > that haven't changed aren't going back into the pool to be rewritten >>> (and >>> > perhaps favored because of low write-cycle count). As the disk fills >>> up, the >>> > blocks that aren't locked up get reused more and more, leading to >>> extra wear >>> > on them. Eventually one of those will get to the point of erroring >>> out. >>> > >>> >Personally, I just size generously but that isn't always an option >>> for >>> > everybody. >>> >>> I have a ZFS RaidZ2 on SSDs that has been running for several /years >>> /without any problems. The drives are Intel 730s, which Intel CLAIMS >>> don't have power-loss protection but in fact appear to; not only do they >>> have caps in them but in addition they pass a "pull the cord out of the >>> wall and then check to see if the data is corrupted on restart" test on >>> a repeated basis, which I did several times before trusting them. >>> >>> BTW essentially all non-data-center SSDs fail that test and some fail it >>> spectacularly (destroying the OS due to some of the in-flight data being >>> comingled on an allocated block with something important; if the >>> read/erase/write cycle interrupts you're cooked as the "other" data that >>> was not being modified gets destroyed too!) -- the Intels are one of the >>> very, very few that have passed it. >>> >>> -- >>> -- Karl Denninger >>> /The Market-Ticker/ >>> S/MIME Email accepted and preferred >>> >> ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD-12.1-RELEASE-amd64.vmdk.xz on VMware vSphere?
Hi, Is there any guide on how to use the vmdk file provided on release on vSphere? The first thing that I noticed is an issue reported a few months ago - https://forums.freebsd.org/threads/installing-on-esxi-using-official-vmdk-files.72945/ Changing the type (Virtual Device Node) of the disk from SCSI to IDE solves the initial issue, but then growfs fails (also the vSphere complains about the disk image and resizing fails. I workaround this by creating a FBSD(12.1amd64) VM on Workstation Player (free version) and then replacing the disk with the image. Resizing and growfs (on first boot) worked as expected. Then I used the created vmdk file and uploaded it to be used for my VM. It's not very "clean" process, I need to download additional software and I wonder if someone has a better approach or those files are strictly only for VM Workstation? Also it's not very good for automatization... ___ 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: Can't input '\', '|', '_' symbol in Japanese keyboard
Hi. I applied ukbd.c patch, then rebuild world and kernel. The result is "Every symbols on keyboard can input as I expected". In attached file, check result with the same procedure below are described. See attachment file for detail. It seems that my problem is fixed. Thanks. 2020年2月25日(火) 21:06 Hans Petter Selasky : > On 2020-02-25 12:37, Minoru TANABE wrote: > > Hi, all. > > > > I rebuild my system, using current ukbd.c. > > The results are same as Subject. No '\', no '|', no '_'. > > > > See attachment for detail. > > Line240 shows "ugen0.3: at usbus0 (disconnected)" > > > > I press keys '\', '|',(right of '^' '~') > > '\', '_' (right of '/' ''?') order. > > > > I can't input underscore on console keyboard. > > So, "usbconfig -d X.Y dump_device_desc" command was executed via ssh. > > > > Thank you. > > > > Hi, > > It looks like the scancodes are bigger than 128, so this might be > treated like a negative value. Solution: Use hid_get_data_unsigned(). > > Can you try the attached patch? > > --HPS > -- mtan (Minoru TANABE) EMail kotana...@gmail.com FreeBSD pico.mtan.com 12.1-STABLE FreeBSD 12.1-STABLE #0 r358300M: Wed Feb 26 03:06:26 JST 2020 r...@pico.mtan.com:/usr/obj/usr/src/amd64.amd64/sys/PICO amd64 Path: /usr/src Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/stable/12 Relative URL: ^/stable/12 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 358300 Node Kind: directory Schedule: normal Last Changed Author: kib Last Changed Rev: 358288 Last Changed Date: 2020-02-24 21:35:58 +0900 (月, 24 2月 2020) ---<>--- Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.1-STABLE #0 r358300M: Wed Feb 26 03:06:26 JST 2020 r...@pico.mtan.com:/usr/obj/usr/src/amd64.amd64/sys/PICO amd64 FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) VT(efifb): resolution 1920x1200 CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (3696.15-MHz K8-class CPU) Origin="GenuineIntel" Id=0x906ea Family=0x6 Model=0x9e Stepping=10 Features=0xbfebfbff Features2=0x7ffafbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c6fbf Structured Extended Features2=0x4000 Structured Extended Features3=0x9c002400 XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 66778271744 (63684 MB) CPU microcode: updated from 0xb4 to 0xca Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-119 on motherboard Launching APs: 1 7 6 10 11 8 9 2 3 4 5 Timecounter "TSC-low" frequency 1848072926 Hz quality 1000 random: entropy device external interface 000.24 [4336] netmap_init netmap: loaded module [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8111b170, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 nexus0 efirtc0: on motherboard efirtc0: registered as a time-of-day clock, resolution 1.00s cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 350 Event timer "HPET1" frequency 2400 Hz quality 340 Event timer "HPET2" frequency 2400 Hz quality 340 Event timer "HPET3" frequency 2400 Hz quality 340 Event timer "HPET4" frequency 2400 Hz quality 340 Event timer "HPET5" frequency 2400 Hz quality 340 Event timer "HPET6" frequency 2400 Hz quality 340 Event timer "HPET7" frequency 2400 Hz quality 340 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xde00-0xdeff,0xc000-0xcfff,0xd000-0xd1ff irq 16 at device 0.0 on pci1 vgapci0: Boot video device hdac0: mem 0xdf08-0xdf083fff irq 17 at device 0.1 on pci1 xhci0: mem 0xdf13-0xdf13 irq 16 at dev
Re: [FreeBSD-Announce] FreeBSD 12.0 end-of-life
On Mon, 2020-02-24 at 19:01 -0600, Mike Karels wrote: > > From mike Sun Feb 23 17:24:54 2020 > > > Gerard E. Seibert wrote: > > On Sun, 23 Feb 2020 16:27:40 -0600, Mike Karels stated: > > > In this case (a USB failure), I bisected the problem some months ago. > > > The offending commit was an ACPI update. I have not yet "downgraded" > > > to 11.3, but I will when I have enough time. > > Obviously, I am not an expert here, but why can't the update to ACPI be > > reversed and why is it only affecting some systems. And why do you have > > to downgrade to 11.3? What are you running now? > > The update to ACPI was pulled from upstream, and IIRC it included multiple > changes. There have been many updates to ACPI since. I don't have any > idea which part of the change caused the problem, or what it does; no idea > how it affects USB on some systems. I'm running 12.1 now, but USB is > problematical (produces an error message once a second, and my UPS control > doesn't seem to work). > > Mike > There may have been two changes working together to create the problem. At some time last year, changes were made to the usb drivers to be sensitive to acpi data of some sort (maybe something about hubs, I forget the details). That alone may have been fine on most systems, but then a later update of acpi code started causing problems which in the past might not have affected usb but now does. It's just a vague theory, based on my memory of some change happening last year that injected awareness of acpi data into the usb driver subsystem. I wonder if it would be possible to add some sort of tunable to disable that awareness, if nothing else just to see if it's the cause of any usb trouble. -- 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"
Re: Running FreeBSD on M.2 SSD
On 2/25/2020 9:53 AM, John Kennedy wrote: On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: I have often wondered if ZFS is more aggressive with discs, because until very recently any solid state drive I have used ZFS on broke very quicky. ... I've always wondered if ZFS (and other snapshotting file systems) would help kill SSD disks by locking up blocks longer than other filesystems might. For example, I've got snapshot-backups going back, say, a year then those blocks that haven't changed aren't going back into the pool to be rewritten (and perhaps favored because of low write-cycle count). As the disk fills up, the blocks that aren't locked up get reused more and more, leading to extra wear on them. Eventually one of those will get to the point of erroring out. Personally, I just size generously but that isn't always an option for everybody. I have a ZFS RaidZ2 on SSDs that has been running for several /years /without any problems. The drives are Intel 730s, which Intel CLAIMS don't have power-loss protection but in fact appear to; not only do they have caps in them but in addition they pass a "pull the cord out of the wall and then check to see if the data is corrupted on restart" test on a repeated basis, which I did several times before trusting them. BTW essentially all non-data-center SSDs fail that test and some fail it spectacularly (destroying the OS due to some of the in-flight data being comingled on an allocated block with something important; if the read/erase/write cycle interrupts you're cooked as the "other" data that was not being modified gets destroyed too!) -- the Intels are one of the very, very few that have passed it. -- -- Karl Denninger /The Market-Ticker/ S/MIME Email accepted and preferred smime.p7s Description: S/MIME Cryptographic Signature
Re: Running FreeBSD on M.2 SSD
On Feb 25, 2020, at 9:03 AM, Daniel Kalchev wrote: > FreeBSD does not technically have driver for different disks. People asked > whether it is an NVMe device or SATA device, because those interfaces have > different drivers. > > But for FreeBSD, an mechanical SATA, hybrid SATA or SSD SATA will use exactly > the same SATA driver. It depends on the chipset. > > It is possible however, that the timing between the drive and the SATA > controller might be different and that is causing the problem. In a similar vein, I had an old MacBook Pro 2011 model. Its SATA chipset would negotiate SATA III speeds but any disk I/O at that speed would soon lead to widespread data corruption. SATA II drives and slower would be fine: no corruption. The funny thing was that this wasn't an issue when I used earlier versions of macOS: the problem only seemed to manifest when I "upgraded" to Mojave (IIRC). I surmised that maybe at that time period, whatever quirks or workarounds in the earlier OS versions no longer applied, and so whatever had caused the SATA III replacement drive to work (e.g., by force-negotiating at the slower speed) no longer did. :-( So, maybe a quirk/workaround that is in Linux and Windows but not in FreeBSD for you hardware *might* be a possibility? Cheers, Paul. ___ 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: Running FreeBSD on M.2 SSD
On Tue, Feb 25, 2020 at 11:07:48AM +, Pete French wrote: > I have often wondered if ZFS is more aggressive with discs, because until > very recently any solid state drive I have used ZFS on broke very quicky. ... I've always wondered if ZFS (and other snapshotting file systems) would help kill SSD disks by locking up blocks longer than other filesystems might. For example, I've got snapshot-backups going back, say, a year then those blocks that haven't changed aren't going back into the pool to be rewritten (and perhaps favored because of low write-cycle count). As the disk fills up, the blocks that aren't locked up get reused more and more, leading to extra wear on them. Eventually one of those will get to the point of erroring out. Personally, I just size generously but that isn't always an option for everybody. ___ 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: Running FreeBSD on M.2 SSD
If my memory serves well, TRIM was originally not enabled by default on FreeBSD, because there were many drives that claimed to support it, but didn’t, or didn’t support it properly. That sort of is resolved today and WD Green is supposedly relatively recent drive. I am not aware of disabling TRIM creating any kind of problem for data consistency or drive longevity, except that it leads to slower writes, as the drive runs out of pre-erased blocks to write to. This is typically more pronounced on “cheaper” drives like this one where there is not much over-provisioning but much less pronounced on “server” drives that keep certain buffer capacity on the driv eunused for precisely that purpose. But why should a drive without TRIM wear more quickly? Daniel > On 25 Feb 2020, at 16:07, Pete French wrote: > > > > On 25/Feb/2020 13:28, Mario Olofo wrote: >> Good morning all, >> @Pete French, you have trim activated on your SSDs right? I heard that if >> its not activated, the SSD disc can stop working very quickly. > > On the curent dfives, yes, but I have run with trim disabled in the past, It > kinds of depends on the drive - so were horirbly slow on trim, and trim could > be a big bottleneck. Havent seen that on a recent drive though, and they all > now have trim enabled on them. > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
On 25/Feb/2020 13:28, Mario Olofo wrote: Good morning all, @Pete French, you have trim activated on your SSDs right? I heard that if its not activated, the SSD disc can stop working very quickly. On the curent dfives, yes, but I have run with trim disabled in the past, It kinds of depends on the drive - so were horirbly slow on trim, and trim could be a big bottleneck. Havent seen that on a recent drive though, and they all now have trim enabled on them. ___ 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: Running FreeBSD on M.2 SSD
FreeBSD does not technically have driver for different disks. People asked whether it is an NVMe device or SATA device, because those interfaces have different drivers. But for FreeBSD, an mechanical SATA, hybrid SATA or SSD SATA will use exactly the same SATA driver. It depends on the chipset. It is possible however, that the timing between the drive and the SATA controller might be different and that is causing the problem. Did you experiment with different settings of the SATA controller in BIOS? If the problem is related to the size of journal, that might mean for some reason the SSD is slow. About th eonly thing an SSD might be slow for is TRIM. Therefore, TRIM might be your problem if weirdly implemented in that drive … so you might try to disable it and see if the problem goes away. As it’s not a server, I doubt you will notice much of performance drop. You can disable TRIM for ZFS with sysctl vfs.zfs.trim.enabled=0 You can put it in /boot/loader.conf. Do this before writing any data to the pool or even creating the pool. Speaking of that, the output of sysctl kstat.zfs.misc.zio_trim might tell us something. I would advise doing all such tests with ZFS, because it will spot any flaky hardware/setup easily. Daniel > On 25 Feb 2020, at 15:28, Mario Olofo wrote: > > Good morning all, > > @Pete French, you have trim activated on your SSDs right? I heard that if > its not activated, the SSD disc can stop working very quickly. > @Daniel Kalchev, I used UFS2 with SU+J as suggested on the forums for me, > and in this case the filesystem didn't "corrupted", it justs kernel panic > from time to time so I gave up. > I think that the problem was related to the size of the journal, that > become full when I put so many files at once on the system, or was > deadlocks in the version of the OS that I was using. > @Alexander Leidinger I have the original HDD 1TB Hybrid that came with the > notebook will try to reinstall FreeBSD on it to see if it works correctly. > > Besides my notebook been a 2019 model Dell G3 with no customizations other > than the m.2 SSD, I never trust that the system is 100%, so I'll try all > possibilities. > 1- The BIOS received an update last month but I'll look if there's > something newer. > 2- Reinstall the FreeBSD on the Hybrid HDD, but if the problem is the > FreeBSD driver, it'll work correctly on that HD. > 3- Will try with other RAM. This I really don't think that is the problem > because is a brand new notebook, but... who knows =). > > Thank you, > > Mario > ___ 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: Running FreeBSD on M.2 SSD
On 2/25/2020 8:28 AM, Mario Olofo wrote: Good morning all, @Pete French, you have trim activated on your SSDs right? I heard that if its not activated, the SSD disc can stop working very quickly. @Daniel Kalchev, I used UFS2 with SU+J as suggested on the forums for me, and in this case the filesystem didn't "corrupted", it justs kernel panic from time to time so I gave up. I think that the problem was related to the size of the journal, that become full when I put so many files at once on the system, or was deadlocks in the version of the OS that I was using. @Alexander Leidinger I have the original HDD 1TB Hybrid that came with the notebook will try to reinstall FreeBSD on it to see if it works correctly. Besides my notebook been a 2019 model Dell G3 with no customizations other than the m.2 SSD, I never trust that the system is 100%, so I'll try all possibilities. 1- The BIOS received an update last month but I'll look if there's something newer. 2- Reinstall the FreeBSD on the Hybrid HDD, but if the problem is the FreeBSD driver, it'll work correctly on that HD. 3- Will try with other RAM. This I really don't think that is the problem because is a brand new notebook, but... who knows =). Thank you, Mario I have a Lenovo Carbon X1 that has a Samsung nVME SSD in it and it's fine with both FreeBSD12-STABLE and Windows (I have it set up for dual EFI boot using REFIND.) It does not have a "custom" driver for Win10; it is using Microsoft's "built-in" stuff. Zero problems and I beat on it pretty-heavily. -- -- Karl Denninger /The Market-Ticker/ S/MIME Email accepted and preferred smime.p7s Description: S/MIME Cryptographic Signature
Re: Running FreeBSD on M.2 SSD
Good morning all, @Pete French, you have trim activated on your SSDs right? I heard that if its not activated, the SSD disc can stop working very quickly. @Daniel Kalchev, I used UFS2 with SU+J as suggested on the forums for me, and in this case the filesystem didn't "corrupted", it justs kernel panic from time to time so I gave up. I think that the problem was related to the size of the journal, that become full when I put so many files at once on the system, or was deadlocks in the version of the OS that I was using. @Alexander Leidinger I have the original HDD 1TB Hybrid that came with the notebook will try to reinstall FreeBSD on it to see if it works correctly. Besides my notebook been a 2019 model Dell G3 with no customizations other than the m.2 SSD, I never trust that the system is 100%, so I'll try all possibilities. 1- The BIOS received an update last month but I'll look if there's something newer. 2- Reinstall the FreeBSD on the Hybrid HDD, but if the problem is the FreeBSD driver, it'll work correctly on that HD. 3- Will try with other RAM. This I really don't think that is the problem because is a brand new notebook, but... who knows =). Thank you, Mario Em ter., 25 de fev. de 2020 às 08:08, Pete French escreveu: > > > On 25/Feb/2020 10:52, Daniel Kalchev wrote: > > It might well be, that FreeBSD is more agressive with your > motherboard/chipset or does not implement known quirk of that — which might > trigger some edge cases for the SSD. Ultimately, if you can move that SSD > to another motherboard and test it, it would confirm where the issue is. > > I have often wondered if ZFS is more aggressive with discs, because > until very recently any solid state drive I have used ZFS on broke very > quicky. For USB sticks that is not unexpected, but decent SSD's also > seem to last less than a year with ZFS on top. I don't let it bother me > anymore simply always install them in pairs and replace when I start > seeing errors. > > By the way, I am not talking about checksum errors here from ZFS, I am > talking about the drive starting to error into dmesg. Checksum errors I > could belive that I was gettign with UFS in the past and just didnt know > it. But this behaviour is that the drive stops working. Some USB sticks > lasted less than a week. Some earlier SSD's only a month or two. More > recent SSD's are lasting longer, and I dont use USB sticks much anymore. > > I am sure I have mentioned this before and people say that it works for > them, so maybe its my magic touch which causes it. :-) > > -pete. > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Can't input '\', '|', '_' symbol in Japanese keyboard
Ok, I will try tomorrow. # It's over 21:00 at JST-9, Sorry. 2020年2月25日(火) 21:06 Hans Petter Selasky : > On 2020-02-25 12:37, Minoru TANABE wrote: > > Hi, all. > > > > I rebuild my system, using current ukbd.c. > > The results are same as Subject. No '\', no '|', no '_'. > > > > See attachment for detail. > > Line240 shows "ugen0.3: at usbus0 (disconnected)" > > > > I press keys '\', '|',(right of '^' '~') > > '\', '_' (right of '/' ''?') order. > > > > I can't input underscore on console keyboard. > > So, "usbconfig -d X.Y dump_device_desc" command was executed via ssh. > > > > Thank you. > > > > Hi, > > It looks like the scancodes are bigger than 128, so this might be > treated like a negative value. Solution: Use hid_get_data_unsigned(). > > Can you try the attached patch? > > --HPS > -- mtan (Minoru TANABE) EMail kotana...@gmail.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: [FreeBSD-Announce] FreeBSD 12.0 end-of-life
On Mon, 24 Feb 2020 19:01:49 -0600, Mike Karels stated: >The update to ACPI was pulled from upstream, and IIRC it included >multiple changes. There have been many updates to ACPI since. I >don't have any idea which part of the change caused the problem, or >what it does; no idea how it affects USB on some systems. I'm running >12.1 now, but USB is problematical (produces an error message once a >second, and my UPS control doesn't seem to work). > > Mike That is sort of what my problem is also. The error message keeps displaying on the screen making using the PC impossible. I don't feel anyone is going to fix this until enough users are affected. I am on 11.3, and if this isn't fixed before 13.x is released, I may have to try another OS. -- Gerard ___ 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: Can't input '\', '|', '_' symbol in Japanese keyboard
Hi, all. I rebuild my system, using current ukbd.c. The results are same as Subject. No '\', no '|', no '_'. See attachment for detail. Line240 shows "ugen0.3: at usbus0 (disconnected)" I press keys '\', '|',(right of '^' '~') '\', '_' (right of '/' ''?') order. I can't input underscore on console keyboard. So, "usbconfig -d X.Y dump_device_desc" command was executed via ssh. Thank you. -- mtan (Minoru TANABE) Phone 03-3601-3475 EMail kotana...@gmail.com uname -a: FreeBSD pico.mtan.com 12.1-STABLE FreeBSD 12.1-STABLE #0 r358300: Tue Feb 25 19:13:15 JST 2020 m...@pico.mtan.com:/usr/obj/usr/src/amd64.amd64/sys/PICO amd64 svnlite info /usr/src: Path: /usr/src Working Copy Root Path: /usr/src URL: https://svn.freebsd.org/base/stable/12 Relative URL: ^/stable/12 Repository Root: https://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 358300 Node Kind: directory Schedule: normal Last Changed Author: kib Last Changed Rev: 358288 Last Changed Date: 2020-02-24 21:35:58 +0900 (æ, 24 2æ 2020) dmesg: ---<>--- Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.1-STABLE #0 r358300: Tue Feb 25 19:13:15 JST 2020 m...@pico.mtan.com:/usr/obj/usr/src/amd64.amd64/sys/PICO amd64 FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) VT(efifb): resolution 1920x1200 CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (3696.17-MHz K8-class CPU) Origin="GenuineIntel" Id=0x906ea Family=0x6 Model=0x9e Stepping=10 Features=0xbfebfbff Features2=0x7ffafbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x29c6fbf Structured Extended Features2=0x4000 Structured Extended Features3=0x9c002400 XSAVE Features=0xf VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 66778271744 (63684 MB) CPU microcode: updated from 0xb4 to 0xca Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 hardware threads random: unblocking device. ioapic0 irqs 0-119 on motherboard Launching APs: 1 11 10 6 7 4 5 8 9 2 3 Timecounter "TSC-low" frequency 1848084469 Hz quality 1000 random: entropy device external interface 000.24 [4336] netmap_init netmap: loaded module [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0x8111b170, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 nexus0 efirtc0: on motherboard efirtc0: registered as a time-of-day clock, resolution 1.00s cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 350 Event timer "HPET1" frequency 2400 Hz quality 340 Event timer "HPET2" frequency 2400 Hz quality 340 Event timer "HPET3" frequency 2400 Hz quality 340 Event timer "HPET4" frequency 2400 Hz quality 340 Event timer "HPET5" frequency 2400 Hz quality 340 Event timer "HPET6" frequency 2400 Hz quality 340 Event timer "HPET7" frequency 2400 Hz quality 340 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xde00-0xdeff,0xc000-0xcfff,0xd000-0xd1ff irq 16 at device 0.0 on pci1 vgapci0: Boot video device hdac0: mem 0xdf08-0xdf083fff irq 17 at device 0.1 on pci1 xhci0: mem 0xdf13-0xdf13 irq 16 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA usbus0: waiting for BIOS to give up control xhci_interrupt: host controller halted usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) ahci0: port 0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xdf148000-0xdf149fff,0xdf14c000-0xdf14c0ff,0xdf14b000-0xdf14b7ff irq 16 at device 23.0 on pci0 ahci0: AHCI v1.31 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3:
Re: Running FreeBSD on M.2 SSD
On 25/Feb/2020 10:52, Daniel Kalchev wrote: It might well be, that FreeBSD is more agressive with your motherboard/chipset or does not implement known quirk of that — which might trigger some edge cases for the SSD. Ultimately, if you can move that SSD to another motherboard and test it, it would confirm where the issue is. I have often wondered if ZFS is more aggressive with discs, because until very recently any solid state drive I have used ZFS on broke very quicky. For USB sticks that is not unexpected, but decent SSD's also seem to last less than a year with ZFS on top. I don't let it bother me anymore simply always install them in pairs and replace when I start seeing errors. By the way, I am not talking about checksum errors here from ZFS, I am talking about the drive starting to error into dmesg. Checksum errors I could belive that I was gettign with UFS in the past and just didnt know it. But this behaviour is that the drive stops working. Some USB sticks lasted less than a week. Some earlier SSD's only a month or two. More recent SSD's are lasting longer, and I dont use USB sticks much anymore. I am sure I have mentioned this before and people say that it works for them, so maybe its my magic touch which causes it. :-) -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: Running FreeBSD on M.2 SSD
I have had disks, that work “perfectly" under UFS and various RAID controllers (and DOS and Windows), but always reported checksum errors when running under ZFS. It would happen on any motherboard or controller. That made me never use anything but ZFS on data that I cannot recreate 100%, fast… but that is separate story. I labeled those disks bad and they sit in my “museum”. Needless to say some were brand new. Not saying you have this issue, but sharing anecdotal evidence. But I wonder how you discovered you had corruption with UFS? What is observed? It might well be, that FreeBSD is more agressive with your motherboard/chipset or does not implement known quirk of that — which might trigger some edge cases for the SSD. Ultimately, if you can move that SSD to another motherboard and test it, it would confirm where the issue is. Daniel > On 25 Feb 2020, at 3:35, Mario Olofo wrote: > > Hi Mike, thanks for the insight. > > I tried both, but not at the same time. > When I found that the ZFS was corrupting the filesystem, I reinstalled the > FreeBSD using UFS but no luck. > Ulf told me that he had the same problem and it turned out the problem was > a defective RAM, but here I just ran the test 2 times, > one from Dell BIOS Diagnostics Tool and other from mdsched.exe from Windos > 10, but here the RAM is ok... > > Thank you again, > > Mario > ___ 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: Running FreeBSD on M.2 SSD
Hi, > On 25 Feb 2020, at 01:35, Mario Olofo wrote: > > Hi Mike, thanks for the insight. > > I tried both, but not at the same time. > When I found that the ZFS was corrupting the filesystem, I reinstalled the > FreeBSD using UFS but no luck. > Ulf told me that he had the same problem and it turned out the problem was > a defective RAM, but here I just ran the test 2 times, > one from Dell BIOS Diagnostics Tool and other from mdsched.exe from Windos > 10, but here the RAM is ok… Software tests will not always find marginally faulty RAM. If you can, try swapping for known good RAM; or if you have lots of RAM installed, try taking half the RAM out at a time and see if that affects stability. > Thank you again, > > Mario > > Em seg., 24 de fev. de 2020 às 22:15, Mike Karels > escreveu: > [etc] -- Bob Bishop r...@gid.co.uk ___ 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: Can't input '\', '|', '_' symbol in Japanese keyboard
O.K. I'll rebuild my system and check them. Please wait for a result. BTW, "plug the keyboard" means "Physically detach and attach the keyboard" ? Thank you for your reply. 2020年2月25日(火) 17:41 Hans Petter Selasky : > > Hi, > > Can you enable ukbd debug in 12-stable? > > sysctl hw.usb.ukbd.debug=20 > > Then plug the keyboard and then press \ | _ symbols and send me the > resulting dmesg. > > Also: > > usbconfig -d X.Y dump_device_desc > > Where X.Y are the numbers after ugen > > --HPS > -- mtan (Minoru TANABE) EMail kotana...@gmail.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"
