daily CVS update output
Updating src tree: P src/external/mit/xorg/bin/xsetwallpaper/Makefile P src/share/misc/acronyms.comp P src/sys/kern/vfs_lookup.c P src/usr.sbin/puffs/mount_9p/mount_9p.8 P src/usr.sbin/puffs/mount_9p/ninepuffs.c P src/usr.sbin/sysinst/defs.h P src/usr.sbin/sysinst/target.c P src/usr.sbin/sysinst/arch/i386/md.c Updating xsrc tree: U xsrc/local/programs/xsetwallpaper/xsetwallpaper.1 Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 45086547 Feb 11 03:03 ls-lRA.gz
Strange ``tail -f'' behaviour - kqueue-related?
I've been seeing some very odd behaviour lately, with ``tail -f''. I've got a bunch of packages being built (in a chroot sandbox), and occassionally I do a ``tail -f'' on the current package's log file just to make sure it is still making progress. So the file is open by both the package-building shell and the tail process. Occassionally the tail process fails to notice any further changes to the file's size, and just sits there. Indeed, it is now more than 30 minutes since a particular build completed (and the shell has long ago closed the log file), but the tail output is still stuck somewhere in the middle of the file. (I've seen this a few times now, and while it happens again and again, it does not seem predictable on when it might happen.) I'm wondering if some of the recent changes to kqueue might be responsible. I don't ever remember seeing this prior to my recent update from 9.99.92 to .93 I can keep the "hung" tail process around for a while in case of any diagnostic requests. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
upgrade - no more high res console 9.99.93
Hi All! after some time, I upgraded from sources: new kernel, toolchain, etc etc. I have an Intel video card. It no longer shows a high-res framebuffer on startup. To me all looks fine, drm detected & enabled. X11 works. [ 3.991030] kern.module.path=/stand/amd64/9.99.93/modules [ 4.051030] kern info: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 4.051030] kern info: [drm] Driver supports precise vblank timestamp query. [ 4.051030] i915drmkms0: interrupting at ioapic0 pin 16 (i915drmkms0) [ 4.131030] kern info: [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0 [ 4.471033] intelfb0 at i915drmkms0 [ 4.471033] kern info: [drm] DRM_I915_DEBUG enabled [ 4.471033] kern info: [drm] DRM_I915_DEBUG_GEM enabled [ 4.471033] intelfb0: framebuffer at 0xc1326000, size 1366x768, depth 32, stride 5504 [ 5.651030] wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0 [ 5.701030] wsmux1: connecting to wsdisplay0 [ 9.941031] wsdisplay0: screen 1 added (default, vt100 emulation) [ 9.941031] wsdisplay0: screen 2 added (default, vt100 emulation) [ 9.941031] wsdisplay0: screen 3 added (default, vt100 emulation) [ 9.941031] wsdisplay0: screen 4 added (default, vt100 emulation) Riccardo
Re: Bug or no Bug?
On Thu, Feb 10, 2022 at 08:05:36AM -0800, Jason Thorpe wrote: > Honestly, I think it's probably better to disable 'spinout' by > default and have it enabled by a sysctl / option. And possibly the > spin time adjustable by sysctl, too. I like that. Martin
Re: Bug or no Bug?
> On Feb 10, 2022, at 4:58 AM, Martin Husemann wrote: > > The kernel lock is held too long while the graphics card is configured. > I have seen that with some Nvidia cards, where I just have not been able > to boot LOCKDEBUG kernels (example in PR 55185). > > You can patch out the kernel lock spinout code (so the kernel does > not limit the KERNEL_LOCK() spin time and you then can investigate > other locking issues). Maybe we should offer an official option to do > that? Honestly, I think it’s probably better to disable “spinout” by default and have it enabled by a sysctl / option. And possibly the spin time adjustable by sysctl, too. -- thorpej
Re: Dell Precision 3650 issues & sysinst
On Thu, Feb 10, 2022 at 01:02:34PM +0100, Martin Husemann wrote: > Hmm, that used to work - but I may have broken it accidently when fixing > a similar issue for updates recently. I'll try to reproduce it. Yes - it was my change. Testing a fix now, thanks for noticing! Martin
Re: Re: Bug or no Bug?
The kernel lock is held too long while the graphics card is configured. I have seen that with some Nvidia cards, where I just have not been able to boot LOCKDEBUG kernels (example in PR 55185). You can patch out the kernel lock spinout code (so the kernel does not limit the KERNEL_LOCK() spin time and you then can investigate other locking issues). Maybe we should offer an official option to do that? Martin P.S.: only guessing it is the graphics card, something(tm) is taking very long while holding the kernel lock, anything called during autoconfiguration could do that - but also a few other things.
Re: Re: Bug or no Bug?
Hello, the kernel crashes during the boot process after enabling the network. At this point no dump files have been written. As first step I have created a clip from the crash: https://speicherwolke.uni-leipzig.de/index.php/s/jFpEa5TAnJAmEcF As soon as I get a usable crashfile I will make an official bug report. Thank you for your efforts Regards Uwe On Thu, 10 Feb 2022, Manuel Bouyer wrote: Date: Thu, 10 Feb 2022 09:53:07 +0100 From: Manuel Bouyer To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org Subject: [Extern] Re: Bug or no Bug? On Wed, Feb 09, 2022 at 09:22:34PM +0100, 6b...@6bone.informatik.uni-leipzig.de wrote: Hello, I have installed the 9.99.xx kernel on several systems. On most systems there are no problems. On a Dell 2800, the kernel crashes during boot. The problem only occurs if the option LOCKDEBUG is set. options LOCKDEBUG # expensive locking checks/support Should a bug report be made in this case? Or should problems that only occur when LOCKDEBUG is enabled be ignored? Crash with LOCKDEBUG are not expected, so please report. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: Dell Precision 3650 issues & sysinst
On Wed, Feb 09, 2022 at 12:51:51PM -0800, Phil Nelson wrote: > #3 The created partitions on the disk looked good, but the machine > wouldn't boot. After some looking around, it appears that > sysinst does create the MSDOS partition with the efi/boot > directory in it, but does not copy /usr/mdec/*.efi to the > directory. Doing that allowed the machine to boot directly > from the disk. Hmm, that used to work - but I may have broken it accidently when fixing a similar issue for updates recently. I'll try to reproduce it. For the USB boot issue: it might be worth to check a recentish netbsd-9 build (which also gives you older DRM, so your X issue might go away too). You can find this builds here: https://nycdn.NetBSD.org/pub/NetBSD-daily/netbsd-9/latest/ But I guess the missing *.efi copy bug has already been pulled up (if it actually was my recentish change). Martin
Re: Bug or no Bug?
On Wed, Feb 09, 2022 at 09:22:34PM +0100, 6b...@6bone.informatik.uni-leipzig.de wrote: > Hello, > > I have installed the 9.99.xx kernel on several systems. On most systems > there are no problems. On a Dell 2800, the kernel crashes during boot. The > problem only occurs if the option LOCKDEBUG is set. > > options LOCKDEBUG # expensive locking checks/support > > Should a bug report be made in this case? Or should problems that only occur > when LOCKDEBUG is enabled be ignored? Crash with LOCKDEBUG are not expected, so please report. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
