Re: NetBSD-10.0RC
On Mon, 20 Nov 2023 at 03:20, Todd Gruhn wrote: > > On the bottom of nv(4) it says "GeForce GTX" . > > I have a GTX-1660 -- will NetBSD now work with this? It doesn't look like it. You have a Turing based card, with a TU116 core. The latest card that seems to be supported on NetBSD is the 10xx series, via the nouveau driver[1], these use the Pascal microarchitecture. The Turing stuff is the successor to this. Cheers, Ian 1 - https://man.netbsd.org/nouveau.4
Re: zfs pool behavior - is it ever freed?
On Thu, 27 Jul 2023 at 19:28, Greg Troxel wrote: > > Mike Pumford writes: > [snip] > > > If I've read it right there needs to be a mechanism for memory > > pressure to force ZFS to release memory. Doing it after all the > > processes have been swapped to disk is way too late as the chances are > > the system will become non-responsive by then. From memory this was a > > problem FreeBSD had to solve as well. > > It would be interesting to read a description of what they did. That > seems easier than figuring it out from scratch. > I'm not sure they did a lot more than expose the ARC limit as a sysctl. I moved to FreeBSD from Net a few years ago (mainly to get ZFS), and have had similar issues under heavy load with a large ARC. It wouldn't crash or hang, but it would always favour killing something over flushing the ARC under pressure. I did a little bit of digging and got the impression this was the way it was intended to work. (Although reading this thread it may be a little more complex than that. :) ) Once I limited my ARC my problems went away. I limited mine to 16 gig on a 96 gig system, but I was running some processes with high memory usage. I've not had cause to increase it though, and the system runs reliably. It has a few zpools, and I'm running a VM of an iSCSI exposed ZVOL, so it get a decent amount of use. (This is my home system, not a production system, however it does have something like 10 HDDs in, so is often quite I/O loaded). Cheers, Ian
Re: Running NetBSD installer on VM to install on real disk [Was: NetBSD 9.3 UEFI...]
On Mon, 5 Dec 2022 at 12:48, Mayuresh wrote: > > On Sat, Dec 03, 2022 at 02:50:00PM +0100, Martin Husemann wrote: > > I would not go via the VM detour, but instead: > > Just curious, what can go wrong this way. > I have installed OSs (Not NetBSD) using this method in the past, giving the VM full access to the physical disk. however the disk booted in the VM wasn't in use by the host. (Infact, as I was in Windows there's no way to give the VM this low level access to the OSs boot disk). It does seem to be possible to boot QEMU off the host disk under Linux (by pointing it at the block device rather than a partition), but you could really set yourself up for problems. (Qemu writing to the wrong bit of your disk may end badly. :D ) If you try I suspect you could get away with creating the parition in linux first, and setting the partition type, so the NetBSD VM doesn't have to update the partition table at all. It's probably worth unmounting the /boot EFI partitoin in linux too, just to be safe. Oh, and run a 'sync' in linux too, just to be sure, it really does like to cache writes. (I mean it's shouldn't cache writes to critical file system things, but it's best to be sure). You could then probably newfs the partition in the VM and manually expand the base sets and bung on a kernel. (It's been a couple of years since I installed NetBSD, but I assume nothing's changed that would prevent this from working since?) As others have said I'd then manually copy the necessary files to the EFI partiton and setup whatever current bootloader you're using to boot NetBSD. Ian
Re: Feed facility/priority to logger(1) via stdin - desirable extension or bad idea?
On Fri, 7 Oct 2022 at 14:19, Matthias Petermann wrote: > > > - Can what I have in mind already be solved (differently or more > elegantly) with existing tools from the base system? > It's not elegent, but depending on your shell you can abuse tee to do something like: $ echo -e "alert|alert thing\ninfo|less important\n" | tee >(grep "^info|" | cut -c6- | logger -puser.notice) | grep "^alert|" | cut -c7- | logger -plocal0.notice cheers, Ian
Re: NetBSD on a NUC
On Wed, 29 Sept 2021 at 00:26, Carl Brewer wrote: > > On 28/09/2021 5:59 am, Bob Bernstein wrote: > > > My question: other than replacing the NUC's drive, are there useful > > directions in which I might point my efforts? > > NUC's are famous for overheating, SSDs for getting damaged by heat. > Replace the SSD drive, they're cheap, it takes 10 minutes and all you > need is a screwdriver. If it doesn't fix it, you have a spare SSD, > that's a win anyway. >nn Depending on the model of NUC it might also have an onboard SATA header. If you've a spare HD you could try that before buying new hardware. I had a NUC with a cheap samsung SSD that would very occasionally refuse to boot, never fully tracked that one down. Ian
Re: ZFS RAIDZ2 and wd uncorrectable data error - why does ZFS not notice the hardware error?
On Sun, 18 Jul 2021 at 00:30, Greg Troxel wrote: > > [snip] > > Ah, interesting point. I find this confusing, because I thought an > uncorrectable read error would, for disks I've dealt with, cause the > sector to be marked as permanently failed and pending reallocation. > It depends where the failure occurs I expect. A drive could read just fine, but then a damaged cable may cause enough noise that the data doesn't always make it to the controller correctly. > I also didn't realize that wd(4) would issue aother read when there is a > failure, but maybe that's in zfs glue code. > wd has retried for years I think, it certanly used to do that with the soft RAID code. Looks to be set at 5 in the source[1], if I'm looking in the right place. :D I expect if you just use wd devices for ZFS there may be some merit in setting the retries to 1 and letting ZFS deal with it, it'd stop the slow I/O, with the effect of ZFS failing the drive. [snip] > >>5 200 140 yes online positiveReallocated sector count0 > > > > I was expecting to see this value greater than 0 if the drive was > > failing, is the drive bad or the cabling? > > Sectors get marked as failed, and then they actually get reallocated > when you write. > I bet after a dd of /dev/zero that will go up. This is useful to know!. :) Ian 1. https://github.com/NetBSD/src/blob/05082e19134c05f2f4b6eca73223cdc6b5ab09bf/sys/dev/ata/wd.c#L94
Re: ZFS RAIDZ2 and wd uncorrectable data error - why does ZFS not notice the hardware error?
On Wed, 14 Jul 2021 at 12:07, Matthias Petermann wrote: > > Hello all, > > > ``` > [ 87240.313853] wd2: (uncorrectable data error) > [ 87240.313853] wd2d: error reading fsbn 5707914328 of > 5707914328-5707914455 (wd2 bn 5707914328; cn 5662613 tn 6 sn 46) > [ 87465.637977] wd2d: error reading fsbn 5710464152 of > 5710464152-5710464215 (wd2 bn 5710464152; cn 5665143 tn 0 sn 8), xfer > 338, retry 0 > [ 87465.637977] wd2: (uncorrectable data error) > [ 87475.561683] wd2: soft error (corrected) xfer 338 > [ 87506.393194] wd2d: error reading fsbn 5710555128 of > 5710555128-5710555255 (wd2 bn 5710555128; cn 5665233 tn 4 sn 12), xfer > 40, retry 0 > [ 87506.393194] wd2: (uncorrectable data error) > [ 87515.156465] wd2d: error reading fsbn 5710555128 of > 5710555128-5710555255 (wd2 bn 5710555128; cn 5665233 tn 4 sn 12), xfer > 40, retry 1 > ``` > > The whole syslog is full of these messages. What surprises me is that > there are "uncorrectable" data errors in the syslog. Nevertheless, the > data can still be read - albeit very slowly. My assumption was that the > redundancies of RAID2 are being used to compensate for the defects. To > my surprise, ZFS does not seem to have noticed any of these defects: > The wd driver is retrying, (IIRC it retries 3 times) and suceeding on the second or 3rd attempt. (See xfer 338, retry 0, followed by a 'soft error corrected' with the same xfer number 10 seconds later. This is the retry suceeding). This sits below ZFS and therefore ZFS never sees the error. If the read failed 3 times you'd probably get a data error in ZFS. > > For the sake of completeness, here is the issue of S.M.A.R.T. - even if > I find it difficult to interpret: > > ``` > saturn$ doas atactl wd2 smart status > SMART supported, SMART enabled > id value thresh crit collect reliability description raw >1 197 51 yes online positiveRaw read error rate 38669 >3 176 21 yes online positiveSpin-up time6158 >4 1000 no online positiveStart/stop count510 >5 200 140 yes online positiveReallocated sector count0 I was expecting to see this value greater than 0 if the drive was failing, is the drive bad or the cabling? Cheers, Ian
Re: GeForce GTX 680
On Fri, 18 Jun 2021 at 14:04, Todd Gruhn wrote: > > I just recieved a GTX 680. I saw *680 in the nouveau(4) page. > Aparrently that does not also apply to GTX 680. Is anything > known about support for the nVidia GTX 680? If the Wikipedia[1] page is correct that's a GK104, which is listed as supported in 9 and -current.[2] 1 - https://en.wikipedia.org/wiki/GeForce_600_series 2 - https://man.netbsd.org/nouveau.4
