Re: CVS commit: src/sys/dev/ata
Ryo ONODERA writes: > Hi, > > After this commit, NetBSD/amd64-current on my HP Spectre x360 > freezes after acpiacad0 detection (before ld0 detection). > Reverting this commit in latest tree fixes my freeze problem. > > Could you take a look at my problem? > > Thank you. > > === === === > cpu7: CPU max freq 40 Hz > cpu7: TSC freq 199200 Hz > timecounter: Timecounter "TSC" frequency 199200 Hz quality 3000 > uhub0 at usb0: NetBSD (0x) xHCI root hub (0x), class 9/0, rev > 3.00/1.00, > addr 0 > uhub0: 6 ports with 6 removable, self powered > uhub1 at usb1: NetBSD (0x) xHCI root hub (0x), class 9/0, rev > 2.00/1.00, > addr 0 > uhub1: 12 ports with 12 removable, self powered > acpiacad0: AC adapter online. > > (With this commit, freeze here) > > ld0: GPT GUID: 3fda58df-424f-4b48-9fb9-b4c5c037379e > dk0 at ld0: "EFI", 262144 blocks at 2048, type: ntfs > dk1 at ld0: "ROOT", 66955885 blocks at 266240, type: ffs > === === === With LOCKDEBUG option, I have gotten the following panic messages: panic: TAILQ_INSERT_TAIL 0xd305ab82ae0 /usr/src/sys/dev/pckbport/pckbport.c:531 cpu0: Begin traceback... vpanic() at netbsd:vpanic+0x178 snprintf() at netbsd:snprintf pckbport_enqueue_cmd() at netbsd:pckbport_enqueue_cmd+0x3c0 pms_reset_thread() at netbsd:pms_reset_thread+0x94 cpu0: End traceback... Thank you. -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
__predict_false for non-default features
On Mon, Apr 27, 2020 at 11:05:31PM +, Nathanial Sloss wrote:
> Skip pfil_run_hooks if no packet filter configured in kernel.
...
> @@ -398,6 +398,11 @@ pfil_run_hooks(pfil_head_t *ph, struct m
> int ret = 0;
>
> KASSERT(dir == PFIL_IN || dir == PFIL_OUT);
> +
> + if (__predict_false(ph == NULL)) {
> + return ret;
> + }
> +
> if (__predict_false((phlistset = pfil_hook_get(dir, ph)) == NULL)) {
> return ret;
> }
>
Speaking about the nearby code (Nat is not at fault, just following the
example).
I think that __predict_false should be used in esoteric failure modes,
or debug features. This isn't one of them.
The people who use packet filters have it always be true. The default
branch predicting behaviour (if the hint is even used) is probably better.
Re: CVS commit: src/sys
On Tue, Apr 28, 2020 at 05:33:45AM +1000, matthew green wrote: > i would just put it in types.h called __AUDIO_BLK_MS, > and leave a default used in the code if unset. Adding: please consider making the default assume a fast machine. This is the value that will also be used by newly added architectures. I expect new ones will be recently made hardware, so we can add one less value for them to fine-tune in their quest to match existing architectures for performance. Thanks!
re: CVS commit: src/sys
i would just put it in types.h called __AUDIO_BLK_MS, and leave a default used in the code if unset. .mrg.
Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon
> Module Name: src > Committed By: tsutsui > Date: Mon Apr 27 16:57:31 UTC 2020 > > Modified Files: > src/sys/external/bsd/drm2/dist/drm/radeon: radeon_ttm.c > > Log Message: > Fix possible bus_dmamap_load(9) leak. PR/55127 > > "Looks good to me" from riastradh@. > Note it was also commented "that code path is likely to be reached" Mis-quoted, it should be "not likely". > so maybe pullups are not necessary. --- Izumi Tsutsui
Re: CVS commit: src/sys/dev/ata
Hi, After this commit, NetBSD/amd64-current on my HP Spectre x360 freezes after acpiacad0 detection (before ld0 detection). Reverting this commit in latest tree fixes my freeze problem. Could you take a look at my problem? Thank you. === === === cpu7: CPU max freq 40 Hz cpu7: TSC freq 199200 Hz timecounter: Timecounter "TSC" frequency 199200 Hz quality 3000 uhub0 at usb0: NetBSD (0x) xHCI root hub (0x), class 9/0, rev 3.00/1.00, addr 0 uhub0: 6 ports with 6 removable, self powered uhub1 at usb1: NetBSD (0x) xHCI root hub (0x), class 9/0, rev 2.00/1.00, addr 0 uhub1: 12 ports with 12 removable, self powered acpiacad0: AC adapter online. (With this commit, freeze here) ld0: GPT GUID: 3fda58df-424f-4b48-9fb9-b4c5c037379e dk0 at ld0: "EFI", 262144 blocks at 2048, type: ntfs dk1 at ld0: "ROOT", 66955885 blocks at 266240, type: ffs === === === "Jason R Thorpe" writes: > Module Name: src > Committed By: thorpej > Date: Sat Apr 25 00:07:27 UTC 2020 > > Modified Files: > src/sys/dev/ata: ata.c ata_subr.c atavar.h > > Log Message: > Rather than creating a kthread-per-channel, use a threadpool and a > threadpool-job-per-channel for the in-thread-context work that needs > to be done (which is rare). > > On one of my test systems, this results in the total number of LWPs > after multi-user boot dropping from 116 to 78. > > > To generate a diff of this commit: > cvs rdiff -u -r1.155 -r1.156 src/sys/dev/ata/ata.c > cvs rdiff -u -r1.9 -r1.10 src/sys/dev/ata/ata_subr.c > cvs rdiff -u -r1.105 -r1.106 src/sys/dev/ata/atavar.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/sys
On Mon, Apr 27, 2020 at 06:19:18PM +0900, Tetsuya Isaki wrote: > As a result of some discussion here, adding 60+ one-line header > files like is troublesome or annoying. > And I have no good idea to generate a suitable border line from > existing parameters or something. > > Then how about this? > (thanks tsutsui@ for comment about choosing archs) > This #ifdefs may not look elegance, but I think it's simple and > realistic. I'd just move it the whole block into audio.c, but otherwise this sounds like a good step forward. Joerg
Re: CVS commit: [phil-wifi] src/sys/net
On 27/04/2020 08:27, Nathanial Sloss wrote: Module Name:src Committed By: nat Date: Mon Apr 27 07:27:35 UTC 2020 Modified Files: src/sys/net [phil-wifi]: pfil.c Log Message: Skip pfil_run_hooks if no packet filter enabled in the kernel. I thought martin@ moved development of this branch over to hg? https://wiki.netbsd.org/Wifi_renewal_on_hg/ Roy
Re: CVS commit: src/sys
As a result of some discussion here, adding 60+ one-line header files like is troublesome or annoying. And I have no good idea to generate a suitable border line from existing parameters or something. Then how about this? (thanks tsutsui@ for comment about choosing archs) This #ifdefs may not look elegance, but I think it's simple and realistic. Thanks, --- a/sys/dev/audio/audiodef.h +++ b/sys/dev/audio/audiodef.h @@ -43,9 +43,15 @@ #define AUMINNOBLK (3) /* - * Hardware blocksize in msec. - * We use 10 msec as default for most platforms. But it's too severe for - * most m68k. + * Default hardware blocksize in msec. + * + * We use 10 msec for most platforms. This period is good enough to play + * audio and video synchronizely. + * In contrast, for very old platforms, this is usually too short and too + * severe. Also such platforms usually can not play video confortably, so + * it's not so important to make the blocksize shorter. + * In either case, you can overwrite AUDIO_BLK_MS by your kernel + * configuration file if you wish. * * 40 msec was initially choosen for the following reason: * (1 / 40ms) = 25 = 5^2. Thus, the frequency is factored by 5. @@ -53,14 +59,24 @@ * even if the frequency is a multiple of 100 (44100, 48000, etc), * or even if 15625Hz (vs(4)). */ +#if defined(__hppa__) || \ +defined(__m68k__) || \ +defined(__sh3__) || \ +(defined(__sparc__) && !defined(__sparc64__)) || \ +defined(__vax__) +#define AUDIO_TOO_SLOW_ARCHS 1 +#endif + #if !defined(AUDIO_BLK_MS) -# if defined(__m68k__) +# if defined(AUDIO_TOO_SLOW_ARCHS) # define AUDIO_BLK_MS 40 # else # define AUDIO_BLK_MS 10 # endif #endif +#undef AUDIO_TOO_SLOW_ARCHS + /* * Whether the playback mixer use single buffer mode. * It reduces the latency one block but needs machine power. --- Tetsuya Isaki
Re: CVS commit: src/sys/netinet6
On Fri, Apr 24, 2020 at 05:36:55PM +, Jonathan A. Kollasch wrote: > Module Name: src > Committed By: jakllsch > Date: Fri Apr 24 17:36:55 UTC 2020 > > Modified Files: > src/sys/netinet6: in6_proto.c > > Log Message: > Fill in .pr_usrreqs for SOCK_SEQPACKET and SOCK_STREAM variants of SCTP too. > > This should allow these socket types of SCTP to operate on IPv6 family > sockets, as .pr_usrreqs must not be NULL for socreate() to succeed. Thanks for this fix! The one test program I know for sctp now gets further but fails in setsockopt (with a basically GENERIC/amd64 5.99.57 kernel). Test program: hg clone http://www.freediameter.net/hg/freeDiameter cd freeDiameter mkdir build cd build cmake .. make ./tests/testsctp gives: 09:53:15 FATAL! sctp.c:101: CHECK FAILED : fd_sctp_client( &cli.cc_socket, 0, TEST_PORT, &eps ) == 2d != 0 Line 101 is CHECK_SYS( setsockopt(sk, IPPROTO_SCTP, SCTP_RTOINFO, &rtoinfo, sizeof(rtoinfo)) ); Cheers, Thomas
