Re: I am sure it is hardware, ufs_inactive: unlinked
On Wed, Jan 15, 2020 at 07:48:04PM -0500, Greg Troxel wrote: > Ronald Georgia writes: > > > I am running 9.99.36 on an old AMD FX-6300 six core processor. It is > > 2009 maybe? Same age on the power supply and memory, but new hard > > drives. It will run fine for a while (couple of days) then completely > > locks up. I had xconsole open and the last time it locked up I had > > this message: > > > > ufs_inactive: unlinked uno on “/“ has non zero size 0 or block … > > Panic: > > > > Questions for all you hardware gurus. > > What would be the most likely suspect? > > In my experience, memory, power supply, and the mains supply if it's not > on a UPS, and the UPS if it is on a UPS. > > > Is there hardware test software that you use and some what trust? > > sysutils/memtestplus. Beware that there is some funkiness with gcc > newer than netbsd5 and multicore tests, that may be resolved but I'm not > sure. > I think the funkiness got worse to the point it doesn't run correctly if built with modern compilers :-( unfortunately I haven't found an easy answer to fixing it. But I suspect netbsd-7 (and possibly netbsd-8?)'s packages work. Other package managers (arch) seem to be downloading the binary & modifying it.
Re: I am sure it is hardware, ufs_inactive: unlinked
Date:Wed, 15 Jan 2020 16:22:12 -0500 From:Ronald Georgia Message-ID: <551ec15b-54a9-4b4e-8788-1450233e5...@gmail.com> | I had xconsole open and the last time it locked up I had this message: It might be hardware, and if the values (if any) in the message (inode number, or anything else) keep varying, then it most likely is, but if you manage to see the same exact message (with numbers, not included in the message, which should be (on one line) something like: ufs_inactive: unlinked ino 1234 on "/" has non zero size 9876 or blocks 456 with allerror 7 where the numbers are all my invention here (and the "/" came from your message, that could also vary possibly) remain constant every time you see the message, then it is probably "just" a corrupted filesystem. In that case, get the system into single user mode, and /sbin/clri /dev/rwd0a 1234 where "/dev/rwd0a" is the raw access device (the 'r') of whatever the "/" filesystem is mounted from (could be sdNx or dkN or ldN or various other things as well as wdNx), check by using the "mount" command (just as "mount" without args, on my system I see /dev/dk6 on / type ffs (log, nodevmtime, local) so I would use "/dev/rdk6" , and the "1234" is the number after "ino" in the message. After the clri command finishes, without doing anything else at all, press the "reset" button (or power cycle the system, if there isn't one of those). Boot into single user mode again, and force a full fsck of the root filesystem fsck -f /dev/rwd0a (or whatever, the same device as the clri) and then reboot.If after this you have no further problems, then all is good.If after a while the problems return, then I would really suspect the hardware. kre
daily CVS update output
Updating src tree: P src/common/lib/libc/arch/x86_64/string/bcmp.S P src/common/lib/libc/arch/x86_64/string/memcmp.S P src/doc/CHANGES P src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vnops.c P src/sys/arch/aarch64/aarch64/cpu.c P src/sys/arch/aarch64/aarch64/cpufunc.c P src/sys/arch/aarch64/aarch64/locore.S P src/sys/arch/aarch64/conf/files.aarch64 P src/sys/arch/aarch64/include/cpu.h P src/sys/arch/aarch64/include/cpufunc.h P src/sys/arch/amd64/amd64/locore.S U src/sys/arch/arm/arm/arm_cpu_topology.c P src/sys/arch/arm/arm32/cpu.c P src/sys/arch/arm/conf/files.arm P src/sys/arch/arm/imx/fdt/imx6_i2c.c P src/sys/arch/arm/imx/fdt/imx8mq_ccm.c P src/sys/arch/arm/include/cpu.h U src/sys/arch/arm/include/cpu_topology.h P src/sys/arch/evbarm/conf/GENERIC64 P src/sys/arch/evbarm/netwalker/netwalker_lcd.c P src/sys/arch/evbarm/netwalker/netwalker_spi.c P src/sys/arch/evbarm/netwalker/netwalker_usb.c P src/sys/arch/i386/i386/locore.S P src/sys/arch/x86/include/cpu.h P src/sys/arch/x86/x86/x86_tlb.c P src/sys/dev/i2c/at24cxx.c P src/sys/dev/i2c/tsl256x.c P src/sys/dev/pci/if_ixl.c P src/sys/dev/usb/if_axen.c P src/sys/dev/usb/if_otus.c P src/sys/dev/usb/if_otusvar.h P src/sys/dev/usb/if_upgt.c P src/sys/dev/usb/if_upgtvar.h P src/sys/dev/usb/if_urtwn.c P src/sys/dev/usb/if_urtwnvar.h P src/sys/dev/usb/if_zyd.c P src/sys/dev/usb/if_zydreg.h P src/sys/external/bsd/drm2/dist/drm/drm_gem.c P src/sys/external/bsd/drm2/dist/drm/i915/i915_gem.c P src/sys/external/bsd/drm2/dist/drm/i915/i915_gem_fence.c P src/sys/external/bsd/drm2/include/linux/mm.h P src/sys/miscfs/genfs/genfs_io.c P src/sys/miscfs/genfs/genfs_node.h P src/sys/nfs/nfs_bio.c P src/sys/rump/librump/rumpkern/Makefile.rumpkern P src/sys/rump/librump/rumpkern/vm.c P src/sys/rump/librump/rumpvfs/vm_vfs.c P src/sys/sys/cpu_data.h P src/sys/sys/param.h P src/sys/ufs/lfs/lfs_pages.c P src/sys/ufs/lfs/lfs_segment.c P src/sys/ufs/lfs/lfs_vfsops.c P src/sys/ufs/lfs/ulfs_inode.c P src/sys/ufs/ufs/ufs_inode.c P src/sys/uvm/files.uvm P src/sys/uvm/uvm_anon.c P src/sys/uvm/uvm_aobj.c P src/sys/uvm/uvm_bio.c P src/sys/uvm/uvm_extern.h P src/sys/uvm/uvm_fault.c P src/sys/uvm/uvm_loan.c P src/sys/uvm/uvm_meter.c P src/sys/uvm/uvm_object.c P src/sys/uvm/uvm_object.h P src/sys/uvm/uvm_page.c P src/sys/uvm/uvm_page.h P src/sys/uvm/uvm_page_array.c U src/sys/uvm/uvm_page_status.c P src/sys/uvm/uvm_pager.c P src/sys/uvm/uvm_pdaemon.c P src/sys/uvm/uvm_vnode.c P src/usr.bin/vmstat/vmstat.c P src/usr.sbin/fstyp/hammer.c P src/usr.sbin/fstyp/hammer2.c P src/usr.sbin/sysinst/disklabel.c P src/usr.sbin/sysinst/gpt.c P src/usr.sbin/sysinst/label.c P src/usr.sbin/sysinst/mbr.c P src/usr.sbin/sysinst/partitions.h P src/usr.sbin/sysinst/partman.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 35298397 Jan 16 03:04 ls-lRA.gz
I am sure it is hardware, ufs_inactive: unlinked
All, I am running 9.99.36 on an old AMD FX-6300 six core processor. It is 2009 maybe? Same age on the power supply and memory, but new hard drives. It will run fine for a while (couple of days) then completely locks up. I had xconsole open and the last time it locked up I had this message: ufs_inactive: unlinked uno on “/“ has non zero size 0 or block … Panic: Questions for all you hardware gurus. What would be the most likely suspect? Is there hardware test software that you use and some what trust? -- Ron Georgia “90% of my problems are due to ignorance, the other 10% is because I just don’t know any better.”
Re: nouveau unhappy with EFI
On Wed, Jan 15, 2020 at 01:22:00PM +0100, Lars Reichardt wrote: > On Mon, 29 Jul 2019 10:16:00 +0100 > Patrick Welche wrote: > > > With biosboot set on the root partition of a GPT disk, I can now > > biosboot or EFI boot the same computer. > > > > Thanks to mlelstv@'s hint, I can get a serial console on the EFI side > > with consdev com,0x3f8,115200 > > as well as the biosbooting side. > > > > In both cases, booting with the serial console, X works on this > > nouveau GeForce GTX 680. > > > > However, if I boot without the serial console. I see nothing on > > screen in the EFI case, but all is OK in the biosboot case. (Unsure: > > typing blindly I did not get X to start in the EFI case, but fat > > fingering possible.) > > > > Hi, > > I see about the same behavior with a GT710 booted with efi, either the > machine stops the moment the frame buffer should get activated or the > screen is all black afterwards with the machine running otherwise. > The last lines displayed are: > nouveau0: error: priv: HUB0: 086014 (1a70828c) > nouveau0: info: fb 2048 MiB GDDR5 > > The Situation with a radeon card (either R5 230 or R7 240) is like it > but not entirely. > With bios boot both cards initialize properly during drmkms startup. > With efi boot both hang about 11sec during initialization with the > following messages: > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, trying to reset the VCPU!!! > *ERROR* UVD not responding, giving up!!! > failed initializing UVD (-1). > > the code printing the error messages has some delays and retries that > add up to the delay... > but the framebuffer comes to live afterwards. > In case of the R7 240 no glamor acceleration but that's a different > story. > > I'm not very deep into the drm code but my guess is, something is > missing about taking over/releasing the efi console and thats blocking > proper initialization as said just a guess. > > > Lars > > > - > You will continue to suffer > if you have an emotional reaction to everything that is said to you. > True power is sitting back and observing everything with logic. > If words control you that means everyone else can control you. > Breathe and allow things to pass. > > --- Bruce Lee > Just FYI: there's something wrong about how nouveau sets up interrupts. (We had to force disable MSI, and I think it enabled interrupts once in its own code and once in generic drm code, or something.) It's possible EFI just happens to run into it.
Re: nouveau unhappy with EFI
On Mon, 29 Jul 2019 10:16:00 +0100 Patrick Welche wrote: > With biosboot set on the root partition of a GPT disk, I can now > biosboot or EFI boot the same computer. > > Thanks to mlelstv@'s hint, I can get a serial console on the EFI side > with consdev com,0x3f8,115200 > as well as the biosbooting side. > > In both cases, booting with the serial console, X works on this > nouveau GeForce GTX 680. > > However, if I boot without the serial console. I see nothing on > screen in the EFI case, but all is OK in the biosboot case. (Unsure: > typing blindly I did not get X to start in the EFI case, but fat > fingering possible.) > Hi, I see about the same behavior with a GT710 booted with efi, either the machine stops the moment the frame buffer should get activated or the screen is all black afterwards with the machine running otherwise. The last lines displayed are: nouveau0: error: priv: HUB0: 086014 (1a70828c) nouveau0: info: fb 2048 MiB GDDR5 The Situation with a radeon card (either R5 230 or R7 240) is like it but not entirely. With bios boot both cards initialize properly during drmkms startup. With efi boot both hang about 11sec during initialization with the following messages: *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, trying to reset the VCPU!!! *ERROR* UVD not responding, giving up!!! failed initializing UVD (-1). the code printing the error messages has some delays and retries that add up to the delay... but the framebuffer comes to live afterwards. In case of the R7 240 no glamor acceleration but that's a different story. I'm not very deep into the drm code but my guess is, something is missing about taking over/releasing the efi console and thats blocking proper initialization as said just a guess. Lars - You will continue to suffer if you have an emotional reaction to everything that is said to you. True power is sitting back and observing everything with logic. If words control you that means everyone else can control you. Breathe and allow things to pass. --- Bruce Lee
Re: net/net-snmp build failure on 9.99.37
On Tue, Jan 14, 2020 at 01:28:53PM -0500, Greg Troxel wrote: > This appears to be a broken tar issue surounding hardlinks and Christos > has backed it out. So perhaps update and rebuild and try again. Yes - the reason pax worked is that it didn't use libarchive. On a "broken" box: # ldd /bin/pax /bin/pax: -lutil.7 => /lib/libutil.so.7 -lc.12 => /lib/libc.so.12 # ldd /bin/tar /bin/tar: -larchive.4 => /usr/lib/libarchive.so.4 -lbz2.1 => /usr/lib/libbz2.so.1 -lc.12 => /lib/libc.so.12 -lcrypto.14 => /lib/libcrypto.so.14 -lcrypt.1 => /lib/libcrypt.so.1 -lexpat.2 => /usr/lib/libexpat.so.2 -llzma.2 => /lib/liblzma.so.2 -lpthread.1 => /lib/libpthread.so.1 -lz.1 => /lib/libz.so.1 Cheers, Patrick
Re: Devices without power management support: dm0 dm1 (LVM / Device Mapper prevents ACPI Sleep State 3)
Hello Maya, On 15.01.20 07:55, m...@netbsd.org wrote: Since I don't see any of this in the log, I'm not sure at all whether the code is actually executed. Is it generally the case that all device drivers are "detached" before entering ACPI Sleep state 3? Or could this be a special case? You will need to rebuild the modules, not the kernel. build.sh modules sudo build.sh ... installmodules=/ Is how I usually do it. I hadn't thought of that - thanks for the tip. It works now! The X230 correctly enters ACPI sleep state 3 with the change you have proposed and wakes up without any functional restrictions. How likely is it that the device mapper was only accidentally not taken into account in power management, or whether it should deliberately block the sleep state for technical reasons? If nothing speaks against it, how do we get the patch in syssrc? Should I submit a bug report? Best wishes Matthias smime.p7s Description: S/MIME Cryptographic Signature
