[stos] Re: CVS commit: src/sys/arch
Le 27/05/2020 à 21:33, Andrew Doran a écrit : Module Name:src Committed By: ad Date: Wed May 27 19:33:40 UTC 2020 Modified Files: src/sys/arch/amd64/amd64: cpufunc.S locore.S src/sys/arch/i386/i386: cpufunc.S locore.S src/sys/arch/x86/include: pmap.h src/sys/arch/x86/x86: pmap.c Log Message: - Add a couple of wrapper functions around STOS and MOVS and use them to zero and copy PTEs in preference to memset()/memcpy(). - Remove related SSE / pageidlezero stuff. To generate a diff of this commit: cvs rdiff -u -r1.56 -r1.57 src/sys/arch/amd64/amd64/cpufunc.S cvs rdiff -u -r1.208 -r1.209 src/sys/arch/amd64/amd64/locore.S cvs rdiff -u -r1.42 -r1.43 src/sys/arch/i386/i386/cpufunc.S cvs rdiff -u -r1.184 -r1.185 src/sys/arch/i386/i386/locore.S cvs rdiff -u -r1.121 -r1.122 src/sys/arch/x86/include/pmap.h cvs rdiff -u -r1.395 -r1.396 src/sys/arch/x86/x86/pmap.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -END(x86_stos) +END(x86_movs) The naming convention should also be more explicit I think, because movs does not say if it is b/w/l/q. Don't have anything meaningful to suggest though
Re: CVS commit: src/sys/dev/usb
On Wed, 27 May 2020, Taylor R Campbell wrote: Not really, because we just need to know whether usb_once_init has been run. OK, great! Now, should we use something other than RUN_ONCE, which can both set up and tear down? Sure, that might be better in principle, but there probably aren't that many systems that have hotpluggable USB in which you might unplug _all_ of the USBs and where you really want to save the cost of a couple kernel threads. So not likely worth much effort. I was thinking more in terms of someone using drvctl(8) to cause the detach. But yeah, it's not a very common use-case, so as long as we don't _need_ the decrement, it's not worth losing any sleep. :) Thanks for the reply. ++--+---+ | 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 | ++--+---+
Re: CVS commit: src/sys/dev/usb
> Date: Wed, 27 May 2020 05:28:41 -0700 (PDT) > From: Paul Goyette > > Do you also need to decrement the number of busses when one is > detached? Not really, because we just need to know whether usb_once_init has been run. Now, should we use something other than RUN_ONCE, which can both set up and tear down? Sure, that might be better in principle, but there probably aren't that many systems that have hotpluggable USB in which you might unplug _all_ of the USBs and where you really want to save the cost of a couple kernel threads. So not likely worth much effort.
Re: CVS commit: src/sys/dev/audio
On Wed, May 27, 2020 at 09:46:04PM +0900, Tetsuya Isaki wrote: > Why are playback and recording asymmetric? > > Thanks, I think this is because audio_rmixer_start is used unguarded in audio_open (it doesn't check for the sc_rbusy flag). This isn't the case for pmixer. So, if the audio device is opened for recording for the first time after system resumption, a panic will occur due to an assertion failure (the recording mixer would already be busy). If there's an advantage to not starting the playback mixer on resume if no devices were previously opened we can do that too?
Re: CVS commit: src/sys/dev/audio
nia, At Tue, 26 May 2020 15:20:16 +, Nia Alarie wrote: > Module Name: src > Committed By: nia > Date: Tue May 26 15:20:16 UTC 2020 > > Modified Files: > src/sys/dev/audio: audio.c > > Log Message: > audio: Only restart recording mixer on resume if it's already been started > > > To generate a diff of this commit: > cvs rdiff -u -r1.73 -r1.74 src/sys/dev/audio/audio.c Why are playback and recording asymmetric? Thanks, --- Tetsuya Isaki
Re: CVS commit: src/sys/dev/usb
Do you also need to decrement the number of busses when one is detached? On Wed, 27 May 2020, Nick Hudson wrote: Module Name:src Committed By: skrll Date: Wed May 27 07:17:45 UTC 2020 Modified Files: src/sys/dev/usb: usb.c Log Message: Don't allow open of /dev/usb if there are no attached busses. PR kern/55303 mutex_vector_enter,512: uninitialized lock To generate a diff of this commit: cvs rdiff -u -r1.186 -r1.187 src/sys/dev/usb/usb.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:5ece145a266021866921056! ++--+---+ | 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 | ++--+---+
Re: [virtio] Re: CVS commit: src/sys/dev/pci
Hi, On Wed, May 27, 2020 at 2:20 AM Maxime Villard wrote: > > Hi, > I don't know if this is related to your changes, but kMSan detected one uninit > variable in virtio 3h ago: > > https://syzkaller.appspot.com/text?tag=CrashReport=12084ef610 > > [ 153.4370851] panic: MSan: Uninitialized Kmem Memory From > virtio_pci_setup_interrupts() > [ 153.4448669] cpu0: Begin traceback... > [ 153.4448669] vpanic() at netbsd:vpanic+0x7c1 sys/kern/subr_prf.c:288 > [ 153.4632004] panic() at netbsd:panic+0x1ad sys/kern/subr_prf.c:209 > [ 153.4734357] __msan_warning() at netbsd:__msan_warning+0xe7 > kmsan_report_inline sys/kern/subr_msan.c:239 [inline] > [ 153.4734357] __msan_warning() at netbsd:__msan_warning+0xe7 > sys/kern/subr_msan.c:612 > [ 153.4931985] virtio_pci_free_interrupts() at > netbsd:virtio_pci_free_interrupts+0x1b4 sys/dev/pci/virtio_pci.c:740 > [ 153.5132006] virtio_child_detach() at > netbsd:virtio_child_detach+0x116 sys/dev/pci/virtio.c:924 > [ 153.5331982] vioscsi_detach() at netbsd:vioscsi_detach+0x40d > sys/dev/pci/vioscsi.c:244 > [ 153.5532009] config_detach() at netbsd:config_detach+0x7e3 > sys/kern/subr_autoconf.c:1760 > [ 153.5732017] config_detach_all() at netbsd:config_detach_all+0x29a > sys/kern/subr_autoconf.c:1906 > [ 153.5831984] cpu_reboot() at netbsd:cpu_reboot+0x290 > sys/arch/amd64/amd64/machdep.c:700 > [ 153.6031986] kern_reboot() at netbsd:kern_reboot+0x18f > sys/kern/kern_reboot.c:73 > [ 153.6231980] sys_reboot() at netbsd:sys_reboot+0x28d > > This means that some memory allocated by virtio_pci_setup_interrupts() on > the kmem allocator was not initialized, and later one access to it was made > by virtio_pci_free_interrupts() at l.740 of the file. Thank you for your pointed out. I modified virtio(4) not to allocate unused memory. I guess it fixes the issue. Could you check this? Thanks, yamaguchi
