Re: svn commit: r355828 - head/sys/sys
On Mon, Dec 16, 2019, 9:57 PM Cy Schubert wrote: > In message > om> > , Warner Losh writes: > > --9630860599df06a0 > > Content-Type: text/plain; charset="UTF-8" > > > > On Mon, Dec 16, 2019, 9:42 PM Cy Schubert > wrote: > > > > > In message <201912162355.xbgntuq6078...@repo.freebsd.org>, "Pedro F. > > > Giffuni" w > > > rites: > > > > Author: pfg > > > > Date: Mon Dec 16 23:55:30 2019 > > > > New Revision: 355828 > > > > URL: https://svnweb.freebsd.org/changeset/base/355828 > > > > > > > > Log: > > > > Double the size of ARG_MAX on LP64 platforms. > > > > > > > > As modern software keeps growing in size, we get requests to > update the > > > > value of ARG_MAX in order to link the resulting object files. > Other OSs > > > > have much higher values but Increasiong ARG_MAX has a multiplied > > > effect on > > > > KVA, so just bumping this value is dangerous in some archs like > ARM32 > > > that > > > > can exhaust KVA rather easily. > > > > > > > > While it would be better to have a unique value for all archs, > other > > > OSs > > > > (Illumos in partidular) can have different ARG_MAX limits > depending on > > > the > > > > platform, For now we want to be really conservative so we are > avoidng > > > > the change on ILP32 and in the alternative case we only double it > > > since tha > > > > t > > > > seems to work well enough for recent Code Aster. > > > > > > > > I was planning to bump the _FreeBSD_version but it was bumped > recently > > > > (r355798) so we can reuse the 1300068 value for this change. > > > > > > This doesn't seem right. Each bump should be for a distinct change and > > > documented as such. > > > > > > > In the past we've said to piggy back versions when less than a day has > > passed since the last bump. The hard part on this is that follow through > on > > actually documenting both has been lax. > > We document this kind of thing on the wiki, but the PITA of opening a > browser. Would it be better to have a similar type of file like RELNOTES > and UPDATING to document version bumps? It seems a little silly, though, > to > have yet another file, maybe we could incorporate that into RELNOTES in > the > form of: > > rNN: > Some verbiage. > We document it in the porters handbook. But I do see the appeal of being able to find it in a svn log param.h. too bad the version bumps aren't all usefully documented in the commit message... porters handbook is the best source Warner Warner -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355828 - head/sys/sys
In message , Warner Losh writes: > --9630860599df06a0 > Content-Type: text/plain; charset="UTF-8" > > On Mon, Dec 16, 2019, 9:42 PM Cy Schubert wrote: > > > In message <201912162355.xbgntuq6078...@repo.freebsd.org>, "Pedro F. > > Giffuni" w > > rites: > > > Author: pfg > > > Date: Mon Dec 16 23:55:30 2019 > > > New Revision: 355828 > > > URL: https://svnweb.freebsd.org/changeset/base/355828 > > > > > > Log: > > > Double the size of ARG_MAX on LP64 platforms. > > > > > > As modern software keeps growing in size, we get requests to update the > > > value of ARG_MAX in order to link the resulting object files. Other OSs > > > have much higher values but Increasiong ARG_MAX has a multiplied > > effect on > > > KVA, so just bumping this value is dangerous in some archs like ARM32 > > that > > > can exhaust KVA rather easily. > > > > > > While it would be better to have a unique value for all archs, other > > OSs > > > (Illumos in partidular) can have different ARG_MAX limits depending on > > the > > > platform, For now we want to be really conservative so we are avoidng > > > the change on ILP32 and in the alternative case we only double it > > since tha > > > t > > > seems to work well enough for recent Code Aster. > > > > > > I was planning to bump the _FreeBSD_version but it was bumped recently > > > (r355798) so we can reuse the 1300068 value for this change. > > > > This doesn't seem right. Each bump should be for a distinct change and > > documented as such. > > > > In the past we've said to piggy back versions when less than a day has > passed since the last bump. The hard part on this is that follow through on > actually documenting both has been lax. We document this kind of thing on the wiki, but the PITA of opening a browser. Would it be better to have a similar type of file like RELNOTES and UPDATING to document version bumps? It seems a little silly, though, to have yet another file, maybe we could incorporate that into RELNOTES in the form of: rNN: Some verbiage. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355828 - head/sys/sys
On Mon, Dec 16, 2019, 9:42 PM Cy Schubert wrote: > In message <201912162355.xbgntuq6078...@repo.freebsd.org>, "Pedro F. > Giffuni" w > rites: > > Author: pfg > > Date: Mon Dec 16 23:55:30 2019 > > New Revision: 355828 > > URL: https://svnweb.freebsd.org/changeset/base/355828 > > > > Log: > > Double the size of ARG_MAX on LP64 platforms. > > > > As modern software keeps growing in size, we get requests to update the > > value of ARG_MAX in order to link the resulting object files. Other OSs > > have much higher values but Increasiong ARG_MAX has a multiplied > effect on > > KVA, so just bumping this value is dangerous in some archs like ARM32 > that > > can exhaust KVA rather easily. > > > > While it would be better to have a unique value for all archs, other > OSs > > (Illumos in partidular) can have different ARG_MAX limits depending on > the > > platform, For now we want to be really conservative so we are avoidng > > the change on ILP32 and in the alternative case we only double it > since tha > > t > > seems to work well enough for recent Code Aster. > > > > I was planning to bump the _FreeBSD_version but it was bumped recently > > (r355798) so we can reuse the 1300068 value for this change. > > This doesn't seem right. Each bump should be for a distinct change and > documented as such. > In the past we've said to piggy back versions when less than a day has passed since the last bump. The hard part on this is that follow through on actually documenting both has been lax. Warner Also, it's not like we're saving any build time anyway. sys/syslimits.h > will cause a substantial portion to be rebuilt anyway. > > > > > PR: 241710 > > MFC after: 5 days > > > > Modified: > > head/sys/sys/syslimits.h > > > > Modified: head/sys/sys/syslimits.h > > > = > > = > > --- head/sys/sys/syslimits.h Mon Dec 16 23:08:09 2019(r355827) > > +++ head/sys/sys/syslimits.h Mon Dec 16 23:55:30 2019(r355828) > > @@ -48,7 +48,11 @@ > > * Do not add any new variables here. (See the comment at the end of > > * the file for why.) > > */ > > -#define ARG_MAX 262144 /* max bytes for an exec > functi > > on */ > > +#ifndef __ILP32__ > > +#define ARG_MAX (2 * 256 * 1024) /* max bytes for an exec > functi > > on */ > > +#else > > +#define ARG_MAX (256 * 1024) /* max bytes for > KVA-starved ar > > chs */ > > +#endif > > #ifndef CHILD_MAX > > #define CHILD_MAX 40 /* max simultaneous > processes * > > / > > #endif > > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355828 - head/sys/sys
In message <201912162355.xbgntuq6078...@repo.freebsd.org>, "Pedro F. Giffuni" w rites: > Author: pfg > Date: Mon Dec 16 23:55:30 2019 > New Revision: 355828 > URL: https://svnweb.freebsd.org/changeset/base/355828 > > Log: > Double the size of ARG_MAX on LP64 platforms. > > As modern software keeps growing in size, we get requests to update the > value of ARG_MAX in order to link the resulting object files. Other OSs > have much higher values but Increasiong ARG_MAX has a multiplied effect on > KVA, so just bumping this value is dangerous in some archs like ARM32 that > can exhaust KVA rather easily. > > While it would be better to have a unique value for all archs, other OSs > (Illumos in partidular) can have different ARG_MAX limits depending on the > platform, For now we want to be really conservative so we are avoidng > the change on ILP32 and in the alternative case we only double it since tha > t > seems to work well enough for recent Code Aster. > > I was planning to bump the _FreeBSD_version but it was bumped recently > (r355798) so we can reuse the 1300068 value for this change. This doesn't seem right. Each bump should be for a distinct change and documented as such. Also, it's not like we're saving any build time anyway. sys/syslimits.h will cause a substantial portion to be rebuilt anyway. > > PR: 241710 > MFC after: 5 days > > Modified: > head/sys/sys/syslimits.h > > Modified: head/sys/sys/syslimits.h > = > = > --- head/sys/sys/syslimits.h Mon Dec 16 23:08:09 2019(r355827) > +++ head/sys/sys/syslimits.h Mon Dec 16 23:55:30 2019(r355828) > @@ -48,7 +48,11 @@ > * Do not add any new variables here. (See the comment at the end of > * the file for why.) > */ > -#define ARG_MAX 262144 /* max bytes for an exec functi > on */ > +#ifndef __ILP32__ > +#define ARG_MAX (2 * 256 * 1024) /* max bytes for an exec functi > on */ > +#else > +#define ARG_MAX (256 * 1024) /* max bytes for KVA-starved ar > chs */ > +#endif > #ifndef CHILD_MAX > #define CHILD_MAX 40 /* max simultaneous processes * > / > #endif > -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355843 - head/sys/cam/nvme
Author: imp Date: Tue Dec 17 04:21:35 2019 New Revision: 355843 URL: https://svnweb.freebsd.org/changeset/base/355843 Log: Revert r355831 It wasn't supposed to change the defaults, but actually does. Back this out until that can be sorted out. Modified: head/sys/cam/nvme/nvme_da.c Modified: head/sys/cam/nvme/nvme_da.c == --- head/sys/cam/nvme/nvme_da.c Tue Dec 17 03:30:49 2019(r355842) +++ head/sys/cam/nvme/nvme_da.c Tue Dec 17 04:21:35 2019(r355843) @@ -177,14 +177,6 @@ static int nda_max_trim_entries = NDA_MAX_TRIM_ENTRIES SYSCTL_INT(_kern_cam_nda, OID_AUTO, max_trim, CTLFLAG_RDTUN, _max_trim_entries, NDA_MAX_TRIM_ENTRIES, "Maximum number of BIO_DELETE to send down as a DSM TRIM."); -static int nda_goal_trim_entries = NDA_MAX_TRIM_ENTRIES / 2; -SYSCTL_INT(_kern_cam_nda, OID_AUTO, goal_trim, CTLFLAG_RDTUN, -_goal_trim_entries, NDA_MAX_TRIM_ENTRIES / 2, -"Number of BIO_DELETE to try to accumulate before sending a DSM TRIM."); -static int nda_trim_ticks = 50;/* 50ms ~ 1000 Hz */ -SYSCTL_INT(_kern_cam_nda, OID_AUTO, trim_ticks, CTLFLAG_RDTUN, -_trim_ticks, 50, -"Number of ticks to hold BIO_DELETEs before sending down a trim"); /* * All NVMe media is non-rotational, so all nvme device instances @@ -749,9 +741,6 @@ ndaregister(struct cam_periph *periph, void *arg) free(softc, M_DEVBUF); return(CAM_REQ_CMP_ERR); } - /* Statically set these for the moment */ - cam_iosched_set_trim_goal(softc->cam_iosched, nda_goal_trim_entries); - cam_iosched_set_trim_ticks(softc->cam_iosched, nda_trim_ticks); /* ident_data parsing */ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355842 - head/sys/dev/kbd
Author: kevans
Date: Tue Dec 17 03:30:49 2019
New Revision: 355842
URL: https://svnweb.freebsd.org/changeset/base/355842
Log:
kbd: const'ify a couple of keyboard_driver fields
Nothing modifies these things, but const'ify out of an abundance of caution.
If we could const'ify the definition in each keyboard driver, I likely
would- improper mutations here can lead to misbehavior or slightly more
annoying to debug state.
Modified:
head/sys/dev/kbd/kbdreg.h
Modified: head/sys/dev/kbd/kbdreg.h
==
--- head/sys/dev/kbd/kbdreg.h Tue Dec 17 03:20:37 2019(r355841)
+++ head/sys/dev/kbd/kbdreg.h Tue Dec 17 03:30:49 2019(r355842)
@@ -96,12 +96,17 @@ typedef struct keyboard_switch {
kbd_diag_t *diag;
} keyboard_switch_t;
-/* keyboard driver */
+/*
+ * Keyboard driver definition. Some of these be immutable after definition
+ * time, e.g. one shouldn't be able to rename a driver or use a different kbdsw
+ * entirely, but patching individual methods is acceptable.
+ */
typedef struct keyboard_driver {
SLIST_ENTRY(keyboard_driver) link;
-char *name;
-keyboard_switch_t *kbdsw;
-int(*configure)(int); /* backdoor for the console
driver */
+const char * const name;
+keyboard_switch_t * const kbdsw;
+/* backdoor for the console driver */
+int(* const configure)(int);
} keyboard_driver_t;
/* keyboard */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355841 - head/sys/mips/include
Author: imp Date: Tue Dec 17 03:20:37 2019 New Revision: 355841 URL: https://svnweb.freebsd.org/changeset/base/355841 Log: Two minor issues: (1) Don't define load/store 64 atomics for o32. They aren't atomic there. (2) Add comment about why we need 64 atomic define on n32 only. Modified: head/sys/mips/include/atomic.h Modified: head/sys/mips/include/atomic.h == --- head/sys/mips/include/atomic.h Tue Dec 17 02:02:26 2019 (r355840) +++ head/sys/mips/include/atomic.h Tue Dec 17 03:20:37 2019 (r355841) @@ -345,10 +345,16 @@ atomic_store_rel_##WIDTH(__volatile uint##WIDTH##_t *p } ATOMIC_STORE_LOAD(32) +#if defined(__mips_n64) || defined(__mips_n32) ATOMIC_STORE_LOAD(64) +#endif #undef ATOMIC_STORE_LOAD -#ifdef __mips_n32 +/* + * MIPS n32 is not a LP64 API, so atomic_load_64 isn't defined there. Define it + * here since n32 is an oddball !LP64 but that can do 64-bit atomics. + */ +#if defined(__mips_n32) #defineatomic_load_64 atomic_load_acq_64 #endif ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355837 - head/sys/cam
On Mon, Dec 16, 2019 at 5:54 PM Kevin Bowling
wrote:
>
>
> On Mon, Dec 16, 2019 at 5:44 PM Steven Hartland <
> steven.hartl...@multiplay.co.uk> wrote:
>
>> Sticky keyboard there Warner?
>
>
> LOL
>
Yea. I have a mac with a keyboard with a stuck delete key. I tried to edit
the commit message on a flight to california last week. It screwed up a few
of the commit messages so I quit for the night. I fixed all the others, but
missed this one :(.
On a more serious note the fact that the controllers lie about the
>> underlying
>> location of data, the impact of skipping the TRIM requests can have a
>> much more
>> serious impact than one might think depending on the drive, so this type
>> of
>> optimisation can significantly harm performance instead of increasing it.
>>
>> This was the main reasons we sponsored the initial ZFS TRIM
>> implementation; as
>> drive performance go so bad with no TRIM that SSD's performed worse than
>> HDD's.
>
>
> Have you been able to test the new OpenZFS/ZoF TRIM?
>
> I notice the current FBSD one gets quite beleaguered with highly
> concurrent poudriere as the snapshots are being reaped, I.e TRIMs totally
> swamp r/w ops on the Plextor PCIe SSD I have. I haven’t tried ZoF on this
> machine yet since it is my main workstation but will do so once it is ready
> for mainline.
>
Trims totally swamping r/w ops is why I started this work in the first
place. I'd wager that the new ZoF TRIM code may not be as well tuned as
FreeBSD and/or makes performance assumptions that are unwise in practice.
I've not looked at it to know, but I suspect it is combining adjacent trims
less. If you are using nvd it will shot gun all requests into the device's
queue, which on less than high end enterprise drives can lead to issues
like you described... I'm willing to help people characterize what's going
on, but I won't have time to look into this until sometime in January. In
general, at least for the drives we use, fewer trims that are larger work a
lot better. Also, biasing your I/O selection towards reads by some factor
helps mitigate the trim factor a bit, though they can still swamp if
there's no reads for a short while to keep the trims at bay (which is why I
wrote the pacing code).
Warner
>
>> Now obviously this was some time ago, but I wouldn't be surprised if
>> there's bad
>> hardware / firmware like this still being produced.
>>
>> Given that might be a good idea to make this optional, possibly even opt
>> in not opt
>> out?
>>
>> Regards
>> Steve
>>
>> On 17/12/2019 00:13, Warner Losh wrote:
>> > Author: imp
>> > Date: Tue Dec 17 00:13:45 2019
>> > New Revision: 355837
>> > URL: https://svnweb.freebsd.org/changeset/base/355837
>> >
>> > Log:
>> >Implement bio_speedup
>> >
>> >React to the BIO_SPEED command in the cam io scheduler by completing
>> >as successful BIO_DELETE commands that are pending, up to the length
>> >passed down in the BIO_SPEEDUP cmomand. The length passed down is a
>> >hint for how much space on the drive needs to be recovered. By
>> >completing the BIO_DELETE comomands, this allows the upper layers to
>> >allocate and write to the blocks that were about to be trimmed. Since
>> >FreeBSD implements TRIMSs as advisory, we can eliminliminate them and
>> >go directly to writing.
>> >
>> >The biggest benefit from TRIMS coomes ffrom the drive being able t
>> >ooptimize its free block pool inthe log run. There's little nto no
>> >bene3efit in the shoort term. , sepeciall whn the trim is followed by
>> >a write. Speedup lets us make this tradeoff.
>> >
>> >Reviewed by: kirk, kib
>> >Sponsored by: Netflix
>> >Differential Revision: https://reviews.freebsd.org/D18351
>> >
>> > Modified:
>> >head/sys/cam/cam_iosched.c
>> >
>> > Modified: head/sys/cam/cam_iosched.c
>> >
>> ==
>> > --- head/sys/cam/cam_iosched.cTue Dec 17 00:13:40 2019
>> (r355836)
>> > +++ head/sys/cam/cam_iosched.cTue Dec 17 00:13:45 2019
>> (r355837)
>> > @@ -1534,6 +1534,41 @@ cam_iosched_queue_work(struct cam_iosched_softc
>> *isc,
>> > {
>> >
>> > /*
>> > + * A BIO_SPEEDUP from the uppper layers means that they have a
>> block
>> > + * shortage. At the present, this is only sent when we're trying
>> to
>> > + * allocate blocks, but have a shortage before giving up.
>> bio_length is
>> > + * the size of their shortage. We will complete just enough
>> BIO_DELETEs
>> > + * in the queue to satisfy the need. If bio_length is 0, we'll
>> complete
>> > + * them all. This allows the scheduler to delay BIO_DELETEs to
>> improve
>> > + * read/write performance without worrying about the upper
>> layers. When
>> > + * it's possibly a problem, we respond by pretending the
>> BIO_DELETEs
>> > + * just worked. We can't do anything about the BIO_DELETEs in the
>> > + * hardware, though. We
Re: svn commit: r355837 - head/sys/cam
On Mon, Dec 16, 2019 at 5:43 PM Steven Hartland <
steven.hartl...@multiplay.co.uk> wrote:
> Sticky keyboard there Warner?
>
Yea. I thought I'd fixed all those messages.
> On a more serious note the fact that the controllers lie about the
> underlying
> location of data, the impact of skipping the TRIM requests can have a
> much more
> serious impact than one might think depending on the drive, so this type of
> optimisation can significantly harm performance instead of increasing it.
>
The underlying location of an LBA is never fixed. There's always a
intermediate layer that does the mapping so you can get good performance
writing to the drive in chunks smaller than the erase block. A trim
followed quickly by a write is nearly the same as just doing the write. In
the cases where we have a severe shortage, we'll skip the trim to a block
that's likely to be written to shortly anyway. It's only done when there's
a shortage, and it only affects the trims that we've not yet scheduled.
> This was the main reasons we sponsored the initial ZFS TRIM
> implementation; as
> drive performance go so bad with no TRIM that SSD's performed worse than
> HDD's.
>
Yes. You can't omit trims generally, but when the choice is to freeze all
the other I/O in the system and do every single trim, or skip a few trims
to allow the I/O to flow more quickly, this is an obvious tradeoff. The
reason you want to generally do trim is to keep the write amp on the drive
down. Skipping it occasionally, especially for blocks that will soon be
written, is fine. It won't materially affect the write amp. Turning it off
completely will affect the write amp terribly, on some drive, as you
discovered as the underlying nand pool of blocks get fragmented.
Now obviously this was some time ago, but I wouldn't be surprised if
> there's bad
> hardware / firmware like this still being produced.
>
I've never encountered firmware so bad that this would cause it any
trouble, despite encountering a lot of bad firmware out there... DSM TRIMs
are optional, and nothing requires that they be done. If you do the
overwhelming majority but fail to do so for a few trims, the drive will
still behave decently even with really bad firmware and garbage collection
routines.
> Given that might be a good idea to make this optional, possibly even opt
> in not opt
> out?
>
It's 100% off if you don't use the I/O scheduler with option IOSCHED. Since
the cam io scheduler can delay I/O, this helps when there's a severe
resource shortage in the system (which happens somewhat infrequently). As
such, I viewed it as part of IOSCHED and not something needing a knob to
turn off separately. I had a hard time triggering the shortages that would
exercise the speedup path, and the code review moved the speedup code to an
even less frequent location.
Warner
> Regards
> Steve
>
> On 17/12/2019 00:13, Warner Losh wrote:
> > Author: imp
> > Date: Tue Dec 17 00:13:45 2019
> > New Revision: 355837
> > URL: https://svnweb.freebsd.org/changeset/base/355837
> >
> > Log:
> >Implement bio_speedup
> >
> >React to the BIO_SPEED command in the cam io scheduler by completing
> >as successful BIO_DELETE commands that are pending, up to the length
> >passed down in the BIO_SPEEDUP cmomand. The length passed down is a
> >hint for how much space on the drive needs to be recovered. By
> >completing the BIO_DELETE comomands, this allows the upper layers to
> >allocate and write to the blocks that were about to be trimmed. Since
> >FreeBSD implements TRIMSs as advisory, we can eliminliminate them and
> >go directly to writing.
> >
> >The biggest benefit from TRIMS coomes ffrom the drive being able t
> >ooptimize its free block pool inthe log run. There's little nto no
> >bene3efit in the shoort term. , sepeciall whn the trim is followed by
> >a write. Speedup lets us make this tradeoff.
> >
> >Reviewed by: kirk, kib
> >Sponsored by: Netflix
> >Differential Revision: https://reviews.freebsd.org/D18351
> >
> > Modified:
> >head/sys/cam/cam_iosched.c
> >
> > Modified: head/sys/cam/cam_iosched.c
> >
> ==
> > --- head/sys/cam/cam_iosched.cTue Dec 17 00:13:40 2019
> (r355836)
> > +++ head/sys/cam/cam_iosched.cTue Dec 17 00:13:45 2019
> (r355837)
> > @@ -1534,6 +1534,41 @@ cam_iosched_queue_work(struct cam_iosched_softc
> *isc,
> > {
> >
> > /*
> > + * A BIO_SPEEDUP from the uppper layers means that they have a
> block
> > + * shortage. At the present, this is only sent when we're trying to
> > + * allocate blocks, but have a shortage before giving up.
> bio_length is
> > + * the size of their shortage. We will complete just enough
> BIO_DELETEs
> > + * in the queue to satisfy the need. If bio_length is 0, we'll
> complete
> > + * them all. This allows the scheduler to delay BIO_DELETEs to
>
Re: svn commit: r355831 - head/sys/cam/nvme
On Mon, Dec 16, 2019, 5:28 PM Steven Hartland < steven.hartl...@multiplay.co.uk> wrote: > Be aware that ZFS already does a pretty decent job of this already, so > the statement > about upper layers isn't true for all. It even has different priorities > for different request > types so I'm a little concerned that doing it at both layers could cause > issues. > ZFS' BIO_DELETE scheduling works well for enterprise drives, but needs tuning the further away you get from enterprise performance. I don't anticipate any effect on performance here since this is not enabled by default, unless I've messed something up (and if I have screwed this up, please let me know). I've honestly not tried to enable these things on ZFS. In addition to this if its anything like SSD's numbers of requests are > only a small part > of the story with total trim size being the other one. I this case you > could hit total > desired size with just one BIO_DELETE request. > > With this code what's the impact of this? > You're correct. It tends to be the number of segments and/or the size of the segment. This steers cases where the number of segments dominates. For cases where total size dominates, you're often better off using the I/O scheduler to rate limit the size of the trims. This feature is designed to allow a large number of files to be deleted at once while doing the trims from them a little at a time to even the load out. Warner > On 17/12/2019 00:11, Warner Losh wrote: > > Author: imp > > Date: Tue Dec 17 00:11:48 2019 > > New Revision: 355831 > > URL: https://svnweb.freebsd.org/changeset/base/355831 > > > > Log: > >NVME trim stuff. > > > >Add two sysctls to control pacing of nvme > >trims. kern.cam.nda.X.goal_trim is the number of upper layer > >BIO_DEELETE requests to try to collecet before sending TRIM down too > >the nvme drive. trim_ticks is the number of ticks, at mosot, to wait > >for at least goal_trim BIOS_DELEETE requests to come in. > > > >Trim pacing is useful when a large number off disjoint trims are > >comoing in from the upper layers. Since we have no way to chain > >toogether trims from the upper layers that are sent down, this acts as > >a hueristic to group trims into reasonable sized chunks. What's > >reasonable varies from drive to drive. > > > >Sponsored by: Netflix > > > > Modified: > >head/sys/cam/nvme/nvme_da.c > > > > Modified: head/sys/cam/nvme/nvme_da.c > > > == > > --- head/sys/cam/nvme/nvme_da.c Tue Dec 17 00:10:19 2019 > (r355830) > > +++ head/sys/cam/nvme/nvme_da.c Tue Dec 17 00:11:48 2019 > (r355831) > > @@ -177,6 +177,14 @@ static int nda_max_trim_entries = > NDA_MAX_TRIM_ENTRIES > > SYSCTL_INT(_kern_cam_nda, OID_AUTO, max_trim, CTLFLAG_RDTUN, > > _max_trim_entries, NDA_MAX_TRIM_ENTRIES, > > "Maximum number of BIO_DELETE to send down as a DSM TRIM."); > > +static int nda_goal_trim_entries = NDA_MAX_TRIM_ENTRIES / 2; > > +SYSCTL_INT(_kern_cam_nda, OID_AUTO, goal_trim, CTLFLAG_RDTUN, > > +_goal_trim_entries, NDA_MAX_TRIM_ENTRIES / 2, > > +"Number of BIO_DELETE to try to accumulate before sending a DSM > TRIM."); > > +static int nda_trim_ticks = 50; /* 50ms ~ 1000 Hz */ > > +SYSCTL_INT(_kern_cam_nda, OID_AUTO, trim_ticks, CTLFLAG_RDTUN, > > +_trim_ticks, 50, > > +"Number of ticks to hold BIO_DELETEs before sending down a trim"); > > > > /* > >* All NVMe media is non-rotational, so all nvme device instances > > @@ -741,6 +749,9 @@ ndaregister(struct cam_periph *periph, void *arg) > > free(softc, M_DEVBUF); > > return(CAM_REQ_CMP_ERR); > > } > > + /* Statically set these for the moment */ > > + cam_iosched_set_trim_goal(softc->cam_iosched, > nda_goal_trim_entries); > > + cam_iosched_set_trim_ticks(softc->cam_iosched, nda_trim_ticks); > > > > /* ident_data parsing */ > > > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355832 - head/sys/cam
The order is relaxed. Nothing in the system depends on ordering wrt
BIO_DELETE requests. Apart from flushes, and one softdep thing in UFS,
nothing does ordered writes. In a multithreaded world they don't really
make sense because multiple upper layer consumers race each other to submit
requests anyway...
Warner
On Mon, Dec 16, 2019, 5:32 PM Steven Hartland <
steven.hartl...@multiplay.co.uk> wrote:
> What if any is the impact on request ordering with this new delayed TRIM?
>
> On 17/12/2019 00:13, Warner Losh wrote:
> > Author: imp
> > Date: Tue Dec 17 00:13:21 2019
> > New Revision: 355832
> > URL: https://svnweb.freebsd.org/changeset/base/355832
> >
> > Log:
> >Add rate limiters to TRIM.
> >
> >Add rate limiters to trims. Trims are a bit different than reads or
> >writes in that they can be combined, so some care needs to be taken
> >where we rate limit them. Additional work will be needed to push the
> >working rate limit below the I/O quanta rate for things like IOPS.
> >
> >Sponsored by: Netflix
> >
> > Modified:
> >head/sys/cam/cam_iosched.c
> >
> > Modified: head/sys/cam/cam_iosched.c
> >
> ==
> > --- head/sys/cam/cam_iosched.cTue Dec 17 00:11:48 2019
> (r355831)
> > +++ head/sys/cam/cam_iosched.cTue Dec 17 00:13:21 2019
> (r355832)
> > @@ -755,7 +755,20 @@ cam_iosched_has_io(struct cam_iosched_softc *isc)
> > static inline bool
> > cam_iosched_has_more_trim(struct cam_iosched_softc *isc)
> > {
> > + struct bio *bp;
> >
> > + bp = bioq_first(>trim_queue);
> > +#ifdef CAM_IOSCHED_DYNAMIC
> > + if (do_dynamic_iosched) {
> > + /*
> > + * If we're limiting trims, then defer action on trims
> > + * for a bit.
> > + */
> > + if (bp == NULL ||
> cam_iosched_limiter_caniop(>trim_stats, bp) != 0)
> > + return false;
> > + }
> > +#endif
> > +
> > /*
> >* If we've set a trim_goal, then if we exceed that allow trims
> >* to be passed back to the driver. If we've also set a tick
> timeout
> > @@ -771,8 +784,8 @@ cam_iosched_has_more_trim(struct cam_iosched_softc
> *is
> > return false;
> > }
> >
> > - return !(isc->flags & CAM_IOSCHED_FLAG_TRIM_ACTIVE) &&
> > - bioq_first(>trim_queue);
> > + /* NB: Should perhaps have a max trim active independent of I/O
> limiters */
> > + return !(isc->flags & CAM_IOSCHED_FLAG_TRIM_ACTIVE) && bp != NULL;
> > }
> >
> > #define cam_iosched_sort_queue(isc) ((isc)->sort_io_queue >= 0 ?\
> > @@ -1389,10 +1402,17 @@ cam_iosched_next_trim(struct cam_iosched_softc
> *isc)
> > struct bio *
> > cam_iosched_get_trim(struct cam_iosched_softc *isc)
> > {
> > +#ifdef CAM_IOSCHED_DYNAMIC
> > + struct bio *bp;
> > +#endif
> >
> > if (!cam_iosched_has_more_trim(isc))
> > return NULL;
> > #ifdef CAM_IOSCHED_DYNAMIC
> > + bp = bioq_first(>trim_queue);
> > + if (bp == NULL)
> > + return NULL;
> > +
> > /*
> >* If pending read, prefer that based on current read bias
> setting. The
> >* read bias is shared for both writes and TRIMs, but on TRIMs the
> bias
> > @@ -1414,6 +1434,26 @@ cam_iosched_get_trim(struct cam_iosched_softc
> *isc)
> >*/
> > isc->current_read_bias = isc->read_bias;
> > }
> > +
> > + /*
> > + * See if our current limiter allows this I/O. Because we only
> call this
> > + * here, and not in next_trim, the 'bandwidth' limits for trims
> won't
> > + * work, while the iops or max queued limits will work. It's tricky
> > + * because we want the limits to be from the perspective of the
> > + * "commands sent to the device." To make iops work, we need to
> check
> > + * only here (since we want all the ops we combine to count as
> one). To
> > + * make bw limits work, we'd need to check in next_trim, but that
> would
> > + * have the effect of limiting the iops as seen from the upper
> layers.
> > + */
> > + if (cam_iosched_limiter_iop(>trim_stats, bp) != 0) {
> > + if (iosched_debug)
> > + printf("Can't trim because limiter says no.\n");
> > + isc->trim_stats.state_flags |= IOP_RATE_LIMITED;
> > + return NULL;
> > + }
> > + isc->current_read_bias = isc->read_bias;
> > + isc->trim_stats.state_flags &= ~IOP_RATE_LIMITED;
> > + /* cam_iosched_next_trim below keeps proper book */
> > #endif
> > return cam_iosched_next_trim(isc);
> > }
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355840 - in head: sys/net usr.bin/netstat
Author: glebius
Date: Tue Dec 17 02:02:26 2019
New Revision: 355840
URL: https://svnweb.freebsd.org/changeset/base/355840
Log:
Convert routing statistics to VNET_PCPUSTAT.
Submitted by: ocochard
Reviewed by: melifaro, glebius
Differential Revision:https://reviews.freebsd.org/D22834
Modified:
head/sys/net/route.c
head/sys/net/route.h
head/usr.bin/netstat/route.c
Modified: head/sys/net/route.c
==
--- head/sys/net/route.cTue Dec 17 01:37:02 2019(r355839)
+++ head/sys/net/route.cTue Dec 17 02:02:26 2019(r355840)
@@ -108,9 +108,16 @@ VNET_DEFINE(u_int, rt_add_addr_allfibs) = 1;
SYSCTL_UINT(_net, OID_AUTO, add_addr_allfibs, CTLFLAG_RWTUN | CTLFLAG_VNET,
_NAME(rt_add_addr_allfibs), 0, "");
-VNET_DEFINE(struct rtstat, rtstat);
-#defineV_rtstatVNET(rtstat)
+VNET_PCPUSTAT_DEFINE_STATIC(struct rtstat, rtstat);
+#defineRTSTAT_ADD(name, val) \
+ VNET_PCPUSTAT_ADD(struct rtstat, rtstat, name, (val))
+#defineRTSTAT_INC(name)RTSTAT_ADD(name, 1)
+VNET_PCPUSTAT_SYSINIT(rtstat);
+#ifdef VIMAGE
+VNET_PCPUSTAT_SYSUNINIT(rtstat);
+#endif
+
VNET_DEFINE(struct rib_head *, rt_tables);
#defineV_rt_tables VNET(rt_tables)
@@ -476,7 +483,7 @@ rtalloc1_fib(struct sockaddr *dst, int report, u_long
* which basically means: "cannot get there from here".
*/
miss:
- V_rtstat.rts_unreach++;
+ RTSTAT_INC(rts_unreach);
if (report) {
/*
@@ -587,7 +594,6 @@ rtredirect_fib(struct sockaddr *dst,
{
struct rtentry *rt;
int error = 0;
- short *stat = NULL;
struct rt_addrinfo info;
struct ifaddr *ifa;
struct rib_head *rnh;
@@ -661,8 +667,8 @@ rtredirect_fib(struct sockaddr *dst,
RT_LOCK(rt);
flags = rt->rt_flags;
}
-
- stat = _rtstat.rts_dynamic;
+ if (error == 0)
+ RTSTAT_INC(rts_dynamic);
} else {
/*
@@ -673,7 +679,7 @@ rtredirect_fib(struct sockaddr *dst,
rt->rt_flags &= ~RTF_GATEWAY;
rt->rt_flags |= RTF_MODIFIED;
flags |= RTF_MODIFIED;
- stat = _rtstat.rts_newgateway;
+ RTSTAT_INC(rts_newgateway);
/*
* add the key and gateway (in one malloc'd chunk).
*/
@@ -690,9 +696,7 @@ done:
RTFREE_LOCKED(rt);
out:
if (error)
- V_rtstat.rts_badredirect++;
- else if (stat != NULL)
- (*stat)++;
+ RTSTAT_INC(rts_badredirect);
bzero((caddr_t), sizeof(info));
info.rti_info[RTAX_DST] = dst;
info.rti_info[RTAX_GATEWAY] = gateway;
Modified: head/sys/net/route.h
==
--- head/sys/net/route.hTue Dec 17 01:37:02 2019(r355839)
+++ head/sys/net/route.hTue Dec 17 02:02:26 2019(r355840)
@@ -237,13 +237,14 @@ rt_update_ro_flags(struct route *ro)
/*
* Routing statistics.
*/
-struct rtstat {
- short rts_badredirect;/* bogus redirect calls */
- short rts_dynamic;/* routes created by redirects */
- short rts_newgateway; /* routes modified by redirects */
- short rts_unreach;/* lookups which failed */
- short rts_wildcard; /* lookups satisfied by a wildcard */
+struct rtstat {
+ uint64_t rts_badredirect; /* bogus redirect calls */
+ uint64_t rts_dynamic; /* routes created by redirects */
+ uint64_t rts_newgateway;/* routes modified by redirects */
+ uint64_t rts_unreach; /* lookups which failed */
+ uint64_t rts_wildcard; /* lookups satisfied by a wildcard */
};
+
/*
* Structures for routing messages.
*/
Modified: head/usr.bin/netstat/route.c
==
--- head/usr.bin/netstat/route.cTue Dec 17 01:37:02 2019
(r355839)
+++ head/usr.bin/netstat/route.cTue Dec 17 02:02:26 2019
(r355840)
@@ -776,22 +776,22 @@ rt_stats(void)
xo_emit("{W:rttrash: symbol not in namelist}\n");
return;
}
- kread(rtsaddr, (char *), sizeof (rtstat));
+ kread_counters(rtsaddr, (char *), sizeof (rtstat));
kread(rttaddr, (char *), sizeof (rttrash));
xo_emit("{T:routing}:\n");
#definep(f, m) if (rtstat.f || sflag <= 1) \
xo_emit(m, rtstat.f, plural(rtstat.f))
- p(rts_badredirect, "\t{:bad-redirects/%hu} "
+
svn commit: r355839 - head/lib/libvmmapi
Author: araujo
Date: Tue Dec 17 01:37:02 2019
New Revision: 355839
URL: https://svnweb.freebsd.org/changeset/base/355839
Log:
Forgotten to remove the previous if statement in commit r355838.
MFC after:1 month
Differential Revision:https://reviews.freebsd.org/D19400
Modified:
head/lib/libvmmapi/vmmapi.c
Modified: head/lib/libvmmapi/vmmapi.c
==
--- head/lib/libvmmapi/vmmapi.c Tue Dec 17 01:33:26 2019(r355838)
+++ head/lib/libvmmapi/vmmapi.c Tue Dec 17 01:37:02 2019(r355839)
@@ -106,10 +106,8 @@ int
vm_create(const char *name)
{
/* Try to load vmm(4) module before creating a guest. */
- if (modfind("vmm") < 0) {
- if (modfind("vmm") < 0)
- kldload("vmm");
- }
+ if (modfind("vmm") < 0)
+ kldload("vmm");
return (CREATE((char *)name));
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355838 - head/lib/libvmmapi
Author: araujo
Date: Tue Dec 17 01:33:26 2019
New Revision: 355838
URL: https://svnweb.freebsd.org/changeset/base/355838
Log:
Attempt to load vmm(4) module before creating a guest using vm_create()
wrapper in libvmmapi.
Submitted by: Rob Fairbanks
Reviewed by: jhb
MFC after:1 month
Differential Revision:https://reviews.freebsd.org/D19400
Modified:
head/lib/libvmmapi/vmmapi.c
Modified: head/lib/libvmmapi/vmmapi.c
==
--- head/lib/libvmmapi/vmmapi.c Tue Dec 17 00:13:45 2019(r355837)
+++ head/lib/libvmmapi/vmmapi.c Tue Dec 17 01:33:26 2019(r355838)
@@ -34,7 +34,9 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
+#include
#include
#include
@@ -103,7 +105,11 @@ vm_device_open(const char *name)
int
vm_create(const char *name)
{
-
+ /* Try to load vmm(4) module before creating a guest. */
+ if (modfind("vmm") < 0) {
+ if (modfind("vmm") < 0)
+ kldload("vmm");
+ }
return (CREATE((char *)name));
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355837 - head/sys/cam
On Mon, Dec 16, 2019 at 5:44 PM Steven Hartland <
steven.hartl...@multiplay.co.uk> wrote:
> Sticky keyboard there Warner?
LOL
> On a more serious note the fact that the controllers lie about the
> underlying
> location of data, the impact of skipping the TRIM requests can have a
> much more
> serious impact than one might think depending on the drive, so this type of
> optimisation can significantly harm performance instead of increasing it.
>
> This was the main reasons we sponsored the initial ZFS TRIM
> implementation; as
> drive performance go so bad with no TRIM that SSD's performed worse than
> HDD's.
Have you been able to test the new OpenZFS/ZoF TRIM?
I notice the current FBSD one gets quite beleaguered with highly concurrent
poudriere as the snapshots are being reaped, I.e TRIMs totally swamp r/w
ops on the Plextor PCIe SSD I have. I haven’t tried ZoF on this machine
yet since it is my main workstation but will do so once it is ready for
mainline.
> Now obviously this was some time ago, but I wouldn't be surprised if
> there's bad
> hardware / firmware like this still being produced.
>
> Given that might be a good idea to make this optional, possibly even opt
> in not opt
> out?
>
> Regards
> Steve
>
> On 17/12/2019 00:13, Warner Losh wrote:
> > Author: imp
> > Date: Tue Dec 17 00:13:45 2019
> > New Revision: 355837
> > URL: https://svnweb.freebsd.org/changeset/base/355837
> >
> > Log:
> >Implement bio_speedup
> >
> >React to the BIO_SPEED command in the cam io scheduler by completing
> >as successful BIO_DELETE commands that are pending, up to the length
> >passed down in the BIO_SPEEDUP cmomand. The length passed down is a
> >hint for how much space on the drive needs to be recovered. By
> >completing the BIO_DELETE comomands, this allows the upper layers to
> >allocate and write to the blocks that were about to be trimmed. Since
> >FreeBSD implements TRIMSs as advisory, we can eliminliminate them and
> >go directly to writing.
> >
> >The biggest benefit from TRIMS coomes ffrom the drive being able t
> >ooptimize its free block pool inthe log run. There's little nto no
> >bene3efit in the shoort term. , sepeciall whn the trim is followed by
> >a write. Speedup lets us make this tradeoff.
> >
> >Reviewed by: kirk, kib
> >Sponsored by: Netflix
> >Differential Revision: https://reviews.freebsd.org/D18351
> >
> > Modified:
> >head/sys/cam/cam_iosched.c
> >
> > Modified: head/sys/cam/cam_iosched.c
> >
> ==
> > --- head/sys/cam/cam_iosched.cTue Dec 17 00:13:40 2019
> (r355836)
> > +++ head/sys/cam/cam_iosched.cTue Dec 17 00:13:45 2019
> (r355837)
> > @@ -1534,6 +1534,41 @@ cam_iosched_queue_work(struct cam_iosched_softc
> *isc,
> > {
> >
> > /*
> > + * A BIO_SPEEDUP from the uppper layers means that they have a
> block
> > + * shortage. At the present, this is only sent when we're trying to
> > + * allocate blocks, but have a shortage before giving up.
> bio_length is
> > + * the size of their shortage. We will complete just enough
> BIO_DELETEs
> > + * in the queue to satisfy the need. If bio_length is 0, we'll
> complete
> > + * them all. This allows the scheduler to delay BIO_DELETEs to
> improve
> > + * read/write performance without worrying about the upper layers.
> When
> > + * it's possibly a problem, we respond by pretending the
> BIO_DELETEs
> > + * just worked. We can't do anything about the BIO_DELETEs in the
> > + * hardware, though. We have to wait for them to complete.
> > + */
> > + if (bp->bio_cmd == BIO_SPEEDUP) {
> > + off_t len;
> > + struct bio *nbp;
> > +
> > + len = 0;
> > + while (bioq_first(>trim_queue) &&
> > + (bp->bio_length == 0 || len < bp->bio_length)) {
> > + nbp = bioq_takefirst(>trim_queue);
> > + len += nbp->bio_length;
> > + nbp->bio_error = 0;
> > + biodone(nbp);
> > + }
> > + if (bp->bio_length > 0) {
> > + if (bp->bio_length > len)
> > + bp->bio_resid = bp->bio_length - len;
> > + else
> > + bp->bio_resid = 0;
> > + }
> > + bp->bio_error = 0;
> > + biodone(bp);
> > + return;
> > + }
> > +
> > + /*
> >* If we get a BIO_FLUSH, and we're doing delayed BIO_DELETEs then
> we
> >* set the last tick time to one less than the current ticks minus
> the
> >* delay to force the BIO_DELETEs to be presented to the client
> driver.
> > @@ -1919,8 +1954,8 @@ DB_SHOW_COMMAND(iosched, cam_iosched_db_show)
> > db_printf("Trim Q len %d\n", biolen(>trim_queue));
> >
Re: svn commit: r355837 - head/sys/cam
Sticky keyboard there Warner?
On a more serious note the fact that the controllers lie about the
underlying
location of data, the impact of skipping the TRIM requests can have a
much more
serious impact than one might think depending on the drive, so this type of
optimisation can significantly harm performance instead of increasing it.
This was the main reasons we sponsored the initial ZFS TRIM
implementation; as
drive performance go so bad with no TRIM that SSD's performed worse than
HDD's.
Now obviously this was some time ago, but I wouldn't be surprised if
there's bad
hardware / firmware like this still being produced.
Given that might be a good idea to make this optional, possibly even opt
in not opt
out?
Regards
Steve
On 17/12/2019 00:13, Warner Losh wrote:
Author: imp
Date: Tue Dec 17 00:13:45 2019
New Revision: 355837
URL: https://svnweb.freebsd.org/changeset/base/355837
Log:
Implement bio_speedup
React to the BIO_SPEED command in the cam io scheduler by completing
as successful BIO_DELETE commands that are pending, up to the length
passed down in the BIO_SPEEDUP cmomand. The length passed down is a
hint for how much space on the drive needs to be recovered. By
completing the BIO_DELETE comomands, this allows the upper layers to
allocate and write to the blocks that were about to be trimmed. Since
FreeBSD implements TRIMSs as advisory, we can eliminliminate them and
go directly to writing.
The biggest benefit from TRIMS coomes ffrom the drive being able t
ooptimize its free block pool inthe log run. There's little nto no
bene3efit in the shoort term. , sepeciall whn the trim is followed by
a write. Speedup lets us make this tradeoff.
Reviewed by: kirk, kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18351
Modified:
head/sys/cam/cam_iosched.c
Modified: head/sys/cam/cam_iosched.c
==
--- head/sys/cam/cam_iosched.c Tue Dec 17 00:13:40 2019(r355836)
+++ head/sys/cam/cam_iosched.c Tue Dec 17 00:13:45 2019(r355837)
@@ -1534,6 +1534,41 @@ cam_iosched_queue_work(struct cam_iosched_softc *isc,
{
/*
+* A BIO_SPEEDUP from the uppper layers means that they have a block
+* shortage. At the present, this is only sent when we're trying to
+* allocate blocks, but have a shortage before giving up. bio_length is
+* the size of their shortage. We will complete just enough BIO_DELETEs
+* in the queue to satisfy the need. If bio_length is 0, we'll complete
+* them all. This allows the scheduler to delay BIO_DELETEs to improve
+* read/write performance without worrying about the upper layers. When
+* it's possibly a problem, we respond by pretending the BIO_DELETEs
+* just worked. We can't do anything about the BIO_DELETEs in the
+* hardware, though. We have to wait for them to complete.
+*/
+ if (bp->bio_cmd == BIO_SPEEDUP) {
+ off_t len;
+ struct bio *nbp;
+
+ len = 0;
+ while (bioq_first(>trim_queue) &&
+ (bp->bio_length == 0 || len < bp->bio_length)) {
+ nbp = bioq_takefirst(>trim_queue);
+ len += nbp->bio_length;
+ nbp->bio_error = 0;
+ biodone(nbp);
+ }
+ if (bp->bio_length > 0) {
+ if (bp->bio_length > len)
+ bp->bio_resid = bp->bio_length - len;
+ else
+ bp->bio_resid = 0;
+ }
+ bp->bio_error = 0;
+ biodone(bp);
+ return;
+ }
+
+ /*
* If we get a BIO_FLUSH, and we're doing delayed BIO_DELETEs then we
* set the last tick time to one less than the current ticks minus the
* delay to force the BIO_DELETEs to be presented to the client driver.
@@ -1919,8 +1954,8 @@ DB_SHOW_COMMAND(iosched, cam_iosched_db_show)
db_printf("Trim Q len %d\n", biolen(>trim_queue));
db_printf("read_bias: %d\n", isc->read_bias);
db_printf("current_read_bias: %d\n", isc->current_read_bias);
- db_printf("Trims active %d\n", isc->pend_trim);
- db_printf("Max trims active %d\n", isc->max_trim);
+ db_printf("Trims active %d\n", isc->pend_trims);
+ db_printf("Max trims active %d\n", isc->max_trims);
}
#endif
#endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355832 - head/sys/cam
What if any is the impact on request ordering with this new delayed TRIM?
On 17/12/2019 00:13, Warner Losh wrote:
Author: imp
Date: Tue Dec 17 00:13:21 2019
New Revision: 355832
URL: https://svnweb.freebsd.org/changeset/base/355832
Log:
Add rate limiters to TRIM.
Add rate limiters to trims. Trims are a bit different than reads or
writes in that they can be combined, so some care needs to be taken
where we rate limit them. Additional work will be needed to push the
working rate limit below the I/O quanta rate for things like IOPS.
Sponsored by: Netflix
Modified:
head/sys/cam/cam_iosched.c
Modified: head/sys/cam/cam_iosched.c
==
--- head/sys/cam/cam_iosched.c Tue Dec 17 00:11:48 2019(r355831)
+++ head/sys/cam/cam_iosched.c Tue Dec 17 00:13:21 2019(r355832)
@@ -755,7 +755,20 @@ cam_iosched_has_io(struct cam_iosched_softc *isc)
static inline bool
cam_iosched_has_more_trim(struct cam_iosched_softc *isc)
{
+ struct bio *bp;
+ bp = bioq_first(>trim_queue);
+#ifdef CAM_IOSCHED_DYNAMIC
+ if (do_dynamic_iosched) {
+ /*
+* If we're limiting trims, then defer action on trims
+* for a bit.
+*/
+ if (bp == NULL || cam_iosched_limiter_caniop(>trim_stats,
bp) != 0)
+ return false;
+ }
+#endif
+
/*
* If we've set a trim_goal, then if we exceed that allow trims
* to be passed back to the driver. If we've also set a tick timeout
@@ -771,8 +784,8 @@ cam_iosched_has_more_trim(struct cam_iosched_softc *is
return false;
}
- return !(isc->flags & CAM_IOSCHED_FLAG_TRIM_ACTIVE) &&
- bioq_first(>trim_queue);
+ /* NB: Should perhaps have a max trim active independent of I/O
limiters */
+ return !(isc->flags & CAM_IOSCHED_FLAG_TRIM_ACTIVE) && bp != NULL;
}
#define cam_iosched_sort_queue(isc) ((isc)->sort_io_queue >= 0 ? \
@@ -1389,10 +1402,17 @@ cam_iosched_next_trim(struct cam_iosched_softc *isc)
struct bio *
cam_iosched_get_trim(struct cam_iosched_softc *isc)
{
+#ifdef CAM_IOSCHED_DYNAMIC
+ struct bio *bp;
+#endif
if (!cam_iosched_has_more_trim(isc))
return NULL;
#ifdef CAM_IOSCHED_DYNAMIC
+ bp = bioq_first(>trim_queue);
+ if (bp == NULL)
+ return NULL;
+
/*
* If pending read, prefer that based on current read bias setting. The
* read bias is shared for both writes and TRIMs, but on TRIMs the bias
@@ -1414,6 +1434,26 @@ cam_iosched_get_trim(struct cam_iosched_softc *isc)
*/
isc->current_read_bias = isc->read_bias;
}
+
+ /*
+* See if our current limiter allows this I/O. Because we only call this
+* here, and not in next_trim, the 'bandwidth' limits for trims won't
+* work, while the iops or max queued limits will work. It's tricky
+* because we want the limits to be from the perspective of the
+* "commands sent to the device." To make iops work, we need to check
+* only here (since we want all the ops we combine to count as one). To
+* make bw limits work, we'd need to check in next_trim, but that would
+* have the effect of limiting the iops as seen from the upper layers.
+*/
+ if (cam_iosched_limiter_iop(>trim_stats, bp) != 0) {
+ if (iosched_debug)
+ printf("Can't trim because limiter says no.\n");
+ isc->trim_stats.state_flags |= IOP_RATE_LIMITED;
+ return NULL;
+ }
+ isc->current_read_bias = isc->read_bias;
+ isc->trim_stats.state_flags &= ~IOP_RATE_LIMITED;
+ /* cam_iosched_next_trim below keeps proper book */
#endif
return cam_iosched_next_trim(isc);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355831 - head/sys/cam/nvme
Be aware that ZFS already does a pretty decent job of this already, so the statement about upper layers isn't true for all. It even has different priorities for different request types so I'm a little concerned that doing it at both layers could cause issues. In addition to this if its anything like SSD's numbers of requests are only a small part of the story with total trim size being the other one. I this case you could hit total desired size with just one BIO_DELETE request. With this code what's the impact of this? On 17/12/2019 00:11, Warner Losh wrote: Author: imp Date: Tue Dec 17 00:11:48 2019 New Revision: 355831 URL: https://svnweb.freebsd.org/changeset/base/355831 Log: NVME trim stuff. Add two sysctls to control pacing of nvme trims. kern.cam.nda.X.goal_trim is the number of upper layer BIO_DEELETE requests to try to collecet before sending TRIM down too the nvme drive. trim_ticks is the number of ticks, at mosot, to wait for at least goal_trim BIOS_DELEETE requests to come in. Trim pacing is useful when a large number off disjoint trims are comoing in from the upper layers. Since we have no way to chain toogether trims from the upper layers that are sent down, this acts as a hueristic to group trims into reasonable sized chunks. What's reasonable varies from drive to drive. Sponsored by: Netflix Modified: head/sys/cam/nvme/nvme_da.c Modified: head/sys/cam/nvme/nvme_da.c == --- head/sys/cam/nvme/nvme_da.c Tue Dec 17 00:10:19 2019(r355830) +++ head/sys/cam/nvme/nvme_da.c Tue Dec 17 00:11:48 2019(r355831) @@ -177,6 +177,14 @@ static int nda_max_trim_entries = NDA_MAX_TRIM_ENTRIES SYSCTL_INT(_kern_cam_nda, OID_AUTO, max_trim, CTLFLAG_RDTUN, _max_trim_entries, NDA_MAX_TRIM_ENTRIES, "Maximum number of BIO_DELETE to send down as a DSM TRIM."); +static int nda_goal_trim_entries = NDA_MAX_TRIM_ENTRIES / 2; +SYSCTL_INT(_kern_cam_nda, OID_AUTO, goal_trim, CTLFLAG_RDTUN, +_goal_trim_entries, NDA_MAX_TRIM_ENTRIES / 2, +"Number of BIO_DELETE to try to accumulate before sending a DSM TRIM."); +static int nda_trim_ticks = 50;/* 50ms ~ 1000 Hz */ +SYSCTL_INT(_kern_cam_nda, OID_AUTO, trim_ticks, CTLFLAG_RDTUN, +_trim_ticks, 50, +"Number of ticks to hold BIO_DELETEs before sending down a trim"); /* * All NVMe media is non-rotational, so all nvme device instances @@ -741,6 +749,9 @@ ndaregister(struct cam_periph *periph, void *arg) free(softc, M_DEVBUF); return(CAM_REQ_CMP_ERR); } + /* Statically set these for the moment */ + cam_iosched_set_trim_goal(softc->cam_iosched, nda_goal_trim_entries); + cam_iosched_set_trim_ticks(softc->cam_iosched, nda_trim_ticks); /* ident_data parsing */ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355837 - head/sys/cam
Author: imp
Date: Tue Dec 17 00:13:45 2019
New Revision: 355837
URL: https://svnweb.freebsd.org/changeset/base/355837
Log:
Implement bio_speedup
React to the BIO_SPEED command in the cam io scheduler by completing
as successful BIO_DELETE commands that are pending, up to the length
passed down in the BIO_SPEEDUP cmomand. The length passed down is a
hint for how much space on the drive needs to be recovered. By
completing the BIO_DELETE comomands, this allows the upper layers to
allocate and write to the blocks that were about to be trimmed. Since
FreeBSD implements TRIMSs as advisory, we can eliminliminate them and
go directly to writing.
The biggest benefit from TRIMS coomes ffrom the drive being able t
ooptimize its free block pool inthe log run. There's little nto no
bene3efit in the shoort term. , sepeciall whn the trim is followed by
a write. Speedup lets us make this tradeoff.
Reviewed by: kirk, kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18351
Modified:
head/sys/cam/cam_iosched.c
Modified: head/sys/cam/cam_iosched.c
==
--- head/sys/cam/cam_iosched.c Tue Dec 17 00:13:40 2019(r355836)
+++ head/sys/cam/cam_iosched.c Tue Dec 17 00:13:45 2019(r355837)
@@ -1534,6 +1534,41 @@ cam_iosched_queue_work(struct cam_iosched_softc *isc,
{
/*
+* A BIO_SPEEDUP from the uppper layers means that they have a block
+* shortage. At the present, this is only sent when we're trying to
+* allocate blocks, but have a shortage before giving up. bio_length is
+* the size of their shortage. We will complete just enough BIO_DELETEs
+* in the queue to satisfy the need. If bio_length is 0, we'll complete
+* them all. This allows the scheduler to delay BIO_DELETEs to improve
+* read/write performance without worrying about the upper layers. When
+* it's possibly a problem, we respond by pretending the BIO_DELETEs
+* just worked. We can't do anything about the BIO_DELETEs in the
+* hardware, though. We have to wait for them to complete.
+*/
+ if (bp->bio_cmd == BIO_SPEEDUP) {
+ off_t len;
+ struct bio *nbp;
+
+ len = 0;
+ while (bioq_first(>trim_queue) &&
+ (bp->bio_length == 0 || len < bp->bio_length)) {
+ nbp = bioq_takefirst(>trim_queue);
+ len += nbp->bio_length;
+ nbp->bio_error = 0;
+ biodone(nbp);
+ }
+ if (bp->bio_length > 0) {
+ if (bp->bio_length > len)
+ bp->bio_resid = bp->bio_length - len;
+ else
+ bp->bio_resid = 0;
+ }
+ bp->bio_error = 0;
+ biodone(bp);
+ return;
+ }
+
+ /*
* If we get a BIO_FLUSH, and we're doing delayed BIO_DELETEs then we
* set the last tick time to one less than the current ticks minus the
* delay to force the BIO_DELETEs to be presented to the client driver.
@@ -1919,8 +1954,8 @@ DB_SHOW_COMMAND(iosched, cam_iosched_db_show)
db_printf("Trim Q len %d\n", biolen(>trim_queue));
db_printf("read_bias: %d\n", isc->read_bias);
db_printf("current_read_bias: %d\n", isc->current_read_bias);
- db_printf("Trims active %d\n", isc->pend_trim);
- db_printf("Max trims active %d\n", isc->max_trim);
+ db_printf("Trims active %d\n", isc->pend_trims);
+ db_printf("Max trims active %d\n", isc->max_trims);
}
#endif
#endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355836 - head/sys/ufs/ffs
Author: imp
Date: Tue Dec 17 00:13:40 2019
New Revision: 355836
URL: https://svnweb.freebsd.org/changeset/base/355836
Log:
Add BIO_SPEEDUP signalling to UFS
When we have a resource shortage in UFS, send down a BIO_SPEEDUP to
give the CAM I/O scheduler a heads up that we have a resource shortage
and that it should bias its decisions knowing that.
Reviewed by: kirk, kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18351
Modified:
head/sys/ufs/ffs/ffs_softdep.c
Modified: head/sys/ufs/ffs/ffs_softdep.c
==
--- head/sys/ufs/ffs/ffs_softdep.c Tue Dec 17 00:13:35 2019
(r355835)
+++ head/sys/ufs/ffs/ffs_softdep.c Tue Dec 17 00:13:40 2019
(r355836)
@@ -3343,8 +3343,7 @@ softdep_synchronize(bp, ump, caller1)
bp->bio_length = 0;
bp->bio_done = softdep_synchronize_completed;
bp->bio_caller1 = caller1;
- g_io_request(bp,
- (struct g_consumer *)ump->um_devvp->v_bufobj.bo_private);
+ g_io_request(bp, ump->um_cp);
}
/*
@@ -13353,6 +13352,7 @@ softdep_request_cleanup(fs, vp, cred, resource)
struct ufsmount *ump;
struct mount *mp;
long starttime;
+ size_t resid;
ufs2_daddr_t needed;
int error, failed_vnode;
@@ -13428,6 +13428,10 @@ softdep_request_cleanup(fs, vp, cred, resource)
}
starttime = time_second;
retry:
+ if (resource == FLUSH_BLOCKS_WAIT &&
+ fs->fs_cstotal.cs_nbfree <= needed)
+ g_io_speedup(needed * fs->fs_bsize, BIO_SPEEDUP_TRIM, ,
+ ump->um_cp);
if ((resource == FLUSH_BLOCKS_WAIT && ump->softdep_on_worklist > 0 &&
fs->fs_cstotal.cs_nbfree <= needed) ||
(resource == FLUSH_INODES_WAIT && fs->fs_pendinginodes > 0 &&
@@ -13740,13 +13744,23 @@ static void
check_clear_deps(mp)
struct mount *mp;
{
+ size_t resid;
/*
+* Tell the lower layers that any TRIM or WRITE transactions
+* that have been delayed for performance reasons should
+* proceed to help alleviate the shortage faster.
+*/
+ g_io_speedup(0, BIO_SPEEDUP_TRIM | BIO_SPEEDUP_WRITE, ,
+ VFSTOUFS(mp)->um_cp);
+
+ /*
* If we are suspended, it may be because of our using
* too many inodedeps, so help clear them out.
*/
if (MOUNTEDSUJ(mp) && VFSTOUFS(mp)->softdep_jblocks->jb_suspended)
clear_inodedeps(mp);
+
/*
* General requests for cleanup of backed up dependencies
*/
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355835 - in head/sys: geom sys
Author: imp
Date: Tue Dec 17 00:13:35 2019
New Revision: 355835
URL: https://svnweb.freebsd.org/changeset/base/355835
Log:
Add BIO_SPEEDUP
Add BIO_SPEEDUP bio command and g_io_speedup wrapper. It tells the
lower layers that the upper layers are dealing with some shortage
(dirty pages and/or disk blocks). The lower layers should do what they
can to speed up anything that's been delayed.
The first use will be to tell the CAM I/O scheduler that any TRIM
shaping should be short-circuited because the system needs
blocks. We'll also call it when there's too many resources used by
UFS.
Reviewed by: kirk, kib
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18351
Modified:
head/sys/geom/geom.h
head/sys/geom/geom_io.c
head/sys/sys/bio.h
Modified: head/sys/geom/geom.h
==
--- head/sys/geom/geom.hTue Dec 17 00:13:30 2019(r355834)
+++ head/sys/geom/geom.hTue Dec 17 00:13:35 2019(r355835)
@@ -343,6 +343,7 @@ void g_io_deliver(struct bio *bp, int error);
int g_io_getattr(const char *attr, struct g_consumer *cp, int *len, void *ptr);
int g_io_zonecmd(struct disk_zone_args *zone_args, struct g_consumer *cp);
int g_io_flush(struct g_consumer *cp);
+int g_io_speedup(size_t shortage, u_int flags, size_t *resid, struct
g_consumer *cp);
int g_register_classifier(struct g_classifier_hook *hook);
void g_unregister_classifier(struct g_classifier_hook *hook);
void g_io_request(struct bio *bp, struct g_consumer *cp);
Modified: head/sys/geom/geom_io.c
==
--- head/sys/geom/geom_io.c Tue Dec 17 00:13:30 2019(r355834)
+++ head/sys/geom/geom_io.c Tue Dec 17 00:13:35 2019(r355835)
@@ -340,6 +340,42 @@ g_io_zonecmd(struct disk_zone_args *zone_args, struct
return (error);
}
+/*
+ * Send a BIO_SPEEDUP down the stack. This is used to tell the lower layers
that
+ * the upper layers have detected a resource shortage. The lower layers are
+ * advised to stop delaying I/O that they might be holding for performance
+ * reasons and to schedule it (non-trims) or complete it successfully (trims)
as
+ * quickly as it can. bio_length is the amount of the shortage. This call
+ * should be non-blocking. bio_resid is used to communicate back if the lower
+ * layers couldn't find bio_length worth of I/O to schedule or discard. A
length
+ * of 0 means to do as much as you can (schedule the h/w queues full, discard
+ * all trims). flags are a hint from the upper layers to the lower layers what
+ * operation should be done.
+ */
+int
+g_io_speedup(size_t shortage, u_int flags, size_t *resid, struct g_consumer
*cp)
+{
+ struct bio *bp;
+ int error;
+
+ KASSERT((flags & (BIO_SPEEDUP_TRIM | BIO_SPEEDUP_WRITE)) != 0,
+ ("Invalid flags passed to g_io_speedup: %#x", flags));
+ g_trace(G_T_BIO, "bio_speedup(%s, %zu, %#x)", cp->provider->name,
+ shortage, flags);
+ bp = g_new_bio();
+ if (bp == NULL)
+ return (ENOMEM);
+ bp->bio_cmd = BIO_SPEEDUP;
+ bp->bio_length = shortage;
+ bp->bio_done = NULL;
+ bp->bio_flags |= flags;
+ g_io_request(bp, cp);
+ error = biowait(bp, "gflush");
+ *resid = bp->bio_resid;
+ g_destroy_bio(bp);
+ return (error);
+}
+
int
g_io_flush(struct g_consumer *cp)
{
Modified: head/sys/sys/bio.h
==
--- head/sys/sys/bio.h Tue Dec 17 00:13:30 2019(r355834)
+++ head/sys/sys/bio.h Tue Dec 17 00:13:35 2019(r355835)
@@ -53,6 +53,7 @@
#define BIO_CMD1 0x07/* Available for local hacks */
#define BIO_CMD2 0x08/* Available for local hacks */
#define BIO_ZONE 0x09/* Zone command */
+#define BIO_SPEEDUP0x0a/* Upper layers face shortage */
/* bio_flags */
#define BIO_ERROR 0x01/* An error occurred processing this bio. */
@@ -69,6 +70,9 @@
#definePRINT_BIO_FLAGS "\20\7vlist\6transient_mapping\5unmapped" \
"\4ordered\3onqueue\2done\1error"
+
+#define BIO_SPEEDUP_WRITE 0x4000 /* Resource shortage at upper layers */
+#define BIO_SPEEDUP_TRIM 0x8000 /* Resource shortage at upper layers */
#ifdef _KERNEL
struct disk;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355832 - head/sys/cam
Author: imp
Date: Tue Dec 17 00:13:21 2019
New Revision: 355832
URL: https://svnweb.freebsd.org/changeset/base/355832
Log:
Add rate limiters to TRIM.
Add rate limiters to trims. Trims are a bit different than reads or
writes in that they can be combined, so some care needs to be taken
where we rate limit them. Additional work will be needed to push the
working rate limit below the I/O quanta rate for things like IOPS.
Sponsored by: Netflix
Modified:
head/sys/cam/cam_iosched.c
Modified: head/sys/cam/cam_iosched.c
==
--- head/sys/cam/cam_iosched.c Tue Dec 17 00:11:48 2019(r355831)
+++ head/sys/cam/cam_iosched.c Tue Dec 17 00:13:21 2019(r355832)
@@ -755,7 +755,20 @@ cam_iosched_has_io(struct cam_iosched_softc *isc)
static inline bool
cam_iosched_has_more_trim(struct cam_iosched_softc *isc)
{
+ struct bio *bp;
+ bp = bioq_first(>trim_queue);
+#ifdef CAM_IOSCHED_DYNAMIC
+ if (do_dynamic_iosched) {
+ /*
+* If we're limiting trims, then defer action on trims
+* for a bit.
+*/
+ if (bp == NULL || cam_iosched_limiter_caniop(>trim_stats,
bp) != 0)
+ return false;
+ }
+#endif
+
/*
* If we've set a trim_goal, then if we exceed that allow trims
* to be passed back to the driver. If we've also set a tick timeout
@@ -771,8 +784,8 @@ cam_iosched_has_more_trim(struct cam_iosched_softc *is
return false;
}
- return !(isc->flags & CAM_IOSCHED_FLAG_TRIM_ACTIVE) &&
- bioq_first(>trim_queue);
+ /* NB: Should perhaps have a max trim active independent of I/O
limiters */
+ return !(isc->flags & CAM_IOSCHED_FLAG_TRIM_ACTIVE) && bp != NULL;
}
#define cam_iosched_sort_queue(isc)((isc)->sort_io_queue >= 0 ?\
@@ -1389,10 +1402,17 @@ cam_iosched_next_trim(struct cam_iosched_softc *isc)
struct bio *
cam_iosched_get_trim(struct cam_iosched_softc *isc)
{
+#ifdef CAM_IOSCHED_DYNAMIC
+ struct bio *bp;
+#endif
if (!cam_iosched_has_more_trim(isc))
return NULL;
#ifdef CAM_IOSCHED_DYNAMIC
+ bp = bioq_first(>trim_queue);
+ if (bp == NULL)
+ return NULL;
+
/*
* If pending read, prefer that based on current read bias setting. The
* read bias is shared for both writes and TRIMs, but on TRIMs the bias
@@ -1414,6 +1434,26 @@ cam_iosched_get_trim(struct cam_iosched_softc *isc)
*/
isc->current_read_bias = isc->read_bias;
}
+
+ /*
+* See if our current limiter allows this I/O. Because we only call this
+* here, and not in next_trim, the 'bandwidth' limits for trims won't
+* work, while the iops or max queued limits will work. It's tricky
+* because we want the limits to be from the perspective of the
+* "commands sent to the device." To make iops work, we need to check
+* only here (since we want all the ops we combine to count as one). To
+* make bw limits work, we'd need to check in next_trim, but that would
+* have the effect of limiting the iops as seen from the upper layers.
+*/
+ if (cam_iosched_limiter_iop(>trim_stats, bp) != 0) {
+ if (iosched_debug)
+ printf("Can't trim because limiter says no.\n");
+ isc->trim_stats.state_flags |= IOP_RATE_LIMITED;
+ return NULL;
+ }
+ isc->current_read_bias = isc->read_bias;
+ isc->trim_stats.state_flags &= ~IOP_RATE_LIMITED;
+ /* cam_iosched_next_trim below keeps proper book */
#endif
return cam_iosched_next_trim(isc);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355834 - head/sys/cam
Author: imp
Date: Tue Dec 17 00:13:30 2019
New Revision: 355834
URL: https://svnweb.freebsd.org/changeset/base/355834
Log:
Eliminate the TRIM_ACTIVE flag.
Rather than a trim active flag, have a counter that can be used to
have a absolute limit on the number of trims in flight independent of
any I/O limiting factors.
Sponsored by: Netflix
Modified:
head/sys/cam/cam_iosched.c
Modified: head/sys/cam/cam_iosched.c
==
--- head/sys/cam/cam_iosched.c Tue Dec 17 00:13:26 2019(r355833)
+++ head/sys/cam/cam_iosched.c Tue Dec 17 00:13:30 2019(r355834)
@@ -281,6 +281,8 @@ struct cam_iosched_softc {
int trim_ticks; /* Max ticks to hold trims */
int last_trim_tick; /* Last 'tick' time ld a trim */
int queued_trims; /* Number of trims in the queue
*/
+ int max_trims; /* Maximum number of trims
pending at once */
+ int pend_trims; /* Number of pending trims now
*/
#ifdef CAM_IOSCHED_DYNAMIC
int read_bias; /* Read bias setting */
int current_read_bias; /* Current read bias state */
@@ -707,11 +709,6 @@ cam_iosched_cl_maybe_steer(struct control_loop *clp)
}
#endif
-/*
- * Trim or similar currently pending completion. Should only be set for
- * those drivers wishing only one Trim active at a time.
- */
-#define CAM_IOSCHED_FLAG_TRIM_ACTIVE (1ul << 0)
/* Callout active, and needs to be torn down */
#define CAM_IOSCHED_FLAG_CALLOUT_ACTIVE (1ul << 1)
@@ -784,8 +781,7 @@ cam_iosched_has_more_trim(struct cam_iosched_softc *is
return false;
}
- /* NB: Should perhaps have a max trim active independent of I/O
limiters */
- return !(isc->flags & CAM_IOSCHED_FLAG_TRIM_ACTIVE) && bp != NULL;
+ return isc->pend_trims <= isc->max_trims && bp != NULL;
}
#define cam_iosched_sort_queue(isc)((isc)->sort_io_queue >= 0 ?\
@@ -1109,6 +1105,7 @@ cam_iosched_init(struct cam_iosched_softc **iscp, stru
(*iscp)->sort_io_queue = -1;
bioq_init(&(*iscp)->bio_queue);
bioq_init(&(*iscp)->trim_queue);
+ (*iscp)->max_trims = 1;
#ifdef CAM_IOSCHED_DYNAMIC
if (do_dynamic_iosched) {
bioq_init(&(*iscp)->write_queue);
@@ -1609,7 +1606,7 @@ void
cam_iosched_trim_done(struct cam_iosched_softc *isc)
{
- isc->flags &= ~CAM_IOSCHED_FLAG_TRIM_ACTIVE;
+ isc->pend_trims--;
}
/*
@@ -1677,7 +1674,7 @@ void
cam_iosched_submit_trim(struct cam_iosched_softc *isc)
{
- isc->flags |= CAM_IOSCHED_FLAG_TRIM_ACTIVE;
+ isc->pend_trims++;
}
/*
@@ -1922,8 +1919,8 @@ DB_SHOW_COMMAND(iosched, cam_iosched_db_show)
db_printf("Trim Q len %d\n", biolen(>trim_queue));
db_printf("read_bias: %d\n", isc->read_bias);
db_printf("current_read_bias: %d\n", isc->current_read_bias);
- db_printf("Trim active? %s\n",
- (isc->flags & CAM_IOSCHED_FLAG_TRIM_ACTIVE) ? "yes" : "no");
+ db_printf("Trims active %d\n", isc->pend_trim);
+ db_printf("Max trims active %d\n", isc->max_trim);
}
#endif
#endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355833 - head/sys/cam
Author: imp
Date: Tue Dec 17 00:13:26 2019
New Revision: 355833
URL: https://svnweb.freebsd.org/changeset/base/355833
Log:
Tweak the ddb show cam iosched command a bit.
For each of the different queue types, list the name of the
queue. While it can be worked out from context, this makes it more
useful and clearer.
Sponsored by: Netflix
Modified:
head/sys/cam/cam_iosched.c
Modified: head/sys/cam/cam_iosched.c
==
--- head/sys/cam/cam_iosched.c Tue Dec 17 00:13:21 2019(r355832)
+++ head/sys/cam/cam_iosched.c Tue Dec 17 00:13:26 2019(r355833)
@@ -1903,7 +1903,7 @@ DB_SHOW_COMMAND(iosched, cam_iosched_db_show)
db_printf("in_reads: %d\n", isc->read_stats.in);
db_printf("out_reads: %d\n", isc->read_stats.out);
db_printf("queued_reads: %d\n", isc->read_stats.queued);
- db_printf("Current Q len %d\n", biolen(>bio_queue));
+ db_printf("Read Q len %d\n", biolen(>bio_queue));
db_printf("pending_writes:%d\n", isc->write_stats.pending);
db_printf("min_writes:%d\n", isc->write_stats.min);
db_printf("max_writes:%d\n", isc->write_stats.max);
@@ -1911,7 +1911,7 @@ DB_SHOW_COMMAND(iosched, cam_iosched_db_show)
db_printf("in_writes: %d\n", isc->write_stats.in);
db_printf("out_writes:%d\n", isc->write_stats.out);
db_printf("queued_writes: %d\n", isc->write_stats.queued);
- db_printf("Current Q len %d\n", biolen(>write_queue));
+ db_printf("Write Q len%d\n", biolen(>write_queue));
db_printf("pending_trims: %d\n", isc->trim_stats.pending);
db_printf("min_trims: %d\n", isc->trim_stats.min);
db_printf("max_trims: %d\n", isc->trim_stats.max);
@@ -1919,7 +1919,7 @@ DB_SHOW_COMMAND(iosched, cam_iosched_db_show)
db_printf("in_trims: %d\n", isc->trim_stats.in);
db_printf("out_trims: %d\n", isc->trim_stats.out);
db_printf("queued_trims: %d\n", isc->trim_stats.queued);
- db_printf("Current Q len %d\n", biolen(>trim_queue));
+ db_printf("Trim Q len %d\n", biolen(>trim_queue));
db_printf("read_bias: %d\n", isc->read_bias);
db_printf("current_read_bias: %d\n", isc->current_read_bias);
db_printf("Trim active? %s\n",
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355831 - head/sys/cam/nvme
Author: imp Date: Tue Dec 17 00:11:48 2019 New Revision: 355831 URL: https://svnweb.freebsd.org/changeset/base/355831 Log: NVME trim stuff. Add two sysctls to control pacing of nvme trims. kern.cam.nda.X.goal_trim is the number of upper layer BIO_DEELETE requests to try to collecet before sending TRIM down too the nvme drive. trim_ticks is the number of ticks, at mosot, to wait for at least goal_trim BIOS_DELEETE requests to come in. Trim pacing is useful when a large number off disjoint trims are comoing in from the upper layers. Since we have no way to chain toogether trims from the upper layers that are sent down, this acts as a hueristic to group trims into reasonable sized chunks. What's reasonable varies from drive to drive. Sponsored by: Netflix Modified: head/sys/cam/nvme/nvme_da.c Modified: head/sys/cam/nvme/nvme_da.c == --- head/sys/cam/nvme/nvme_da.c Tue Dec 17 00:10:19 2019(r355830) +++ head/sys/cam/nvme/nvme_da.c Tue Dec 17 00:11:48 2019(r355831) @@ -177,6 +177,14 @@ static int nda_max_trim_entries = NDA_MAX_TRIM_ENTRIES SYSCTL_INT(_kern_cam_nda, OID_AUTO, max_trim, CTLFLAG_RDTUN, _max_trim_entries, NDA_MAX_TRIM_ENTRIES, "Maximum number of BIO_DELETE to send down as a DSM TRIM."); +static int nda_goal_trim_entries = NDA_MAX_TRIM_ENTRIES / 2; +SYSCTL_INT(_kern_cam_nda, OID_AUTO, goal_trim, CTLFLAG_RDTUN, +_goal_trim_entries, NDA_MAX_TRIM_ENTRIES / 2, +"Number of BIO_DELETE to try to accumulate before sending a DSM TRIM."); +static int nda_trim_ticks = 50;/* 50ms ~ 1000 Hz */ +SYSCTL_INT(_kern_cam_nda, OID_AUTO, trim_ticks, CTLFLAG_RDTUN, +_trim_ticks, 50, +"Number of ticks to hold BIO_DELETEs before sending down a trim"); /* * All NVMe media is non-rotational, so all nvme device instances @@ -741,6 +749,9 @@ ndaregister(struct cam_periph *periph, void *arg) free(softc, M_DEVBUF); return(CAM_REQ_CMP_ERR); } + /* Statically set these for the moment */ + cam_iosched_set_trim_goal(softc->cam_iosched, nda_goal_trim_entries); + cam_iosched_set_trim_ticks(softc->cam_iosched, nda_trim_ticks); /* ident_data parsing */ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355830 - head/sys/dev/ata/chipsets
Author: brooks
Date: Tue Dec 17 00:10:19 2019
New Revision: 355830
URL: https://svnweb.freebsd.org/changeset/base/355830
Log:
Avoid a tautological bitwise compare.
This looks like a bit of debugging code that sliped into the initial
import of the new ATA framework. This changes the behavior to omit a
line of output that appears to have been intended for omission.
Reviewed by: mav
MFC after:3 days
Sponsored by: DARPA, AFRL
Differential Revision:https://reviews.freebsd.org/D22845
Modified:
head/sys/dev/ata/chipsets/ata-promise.c
Modified: head/sys/dev/ata/chipsets/ata-promise.c
==
--- head/sys/dev/ata/chipsets/ata-promise.c Tue Dec 17 00:00:03 2019
(r355829)
+++ head/sys/dev/ata/chipsets/ata-promise.c Tue Dec 17 00:10:19 2019
(r355830)
@@ -795,7 +795,7 @@ ata_promise_mio_reset(device_t dev)
if (ata_sata_phy_reset(dev, -1, 1)) {
u_int32_t signature = ch->hw.softreset(dev, ATA_PM);
- if (1 | bootverbose)
+ if (bootverbose)
device_printf(dev, "SIGNATURE: %08x\n", signature);
switch (signature >> 16) {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355829 - head/sys/mips/conf
Author: adrian Date: Tue Dec 17 00:00:03 2019 New Revision: 355829 URL: https://svnweb.freebsd.org/changeset/base/355829 Log: [atheros] [mips] Add the GPIO driver (back) to the TL-WDR3600/TL-WDR4300 kernel. So it turns out that sometime in the past I removed the GPIO bits here and was going to move it into a module in order to save a little space. However, it turns out that was a mistake on this particular AP - it uses a pair of GPIO lines to control the two receive LNAs on the 2GHz radio and without them enabled the radio is a LOT DEAF. With this re-introduced (and some replacement userland tools to save space, *cough* cpio/libarchive) I can actually use these chipsets again as a 2G station. Without the LNA the AP was seeing a per-radio RSSI upstairs here of around 3-5dB, with the LNA on it's around 15dB, more than enough to actually use wifi upstairs and also in line with the other Atheros / Intel devices I have up here. Big oopsie to Adrian. Big, big oopsie. Modified: head/sys/mips/conf/TL-WDR4300 Modified: head/sys/mips/conf/TL-WDR4300 == --- head/sys/mips/conf/TL-WDR4300 Mon Dec 16 23:55:30 2019 (r355828) +++ head/sys/mips/conf/TL-WDR4300 Tue Dec 17 00:00:03 2019 (r355829) @@ -50,5 +50,12 @@ options AR71XX_ATH_EEPROM device firmware# Used by the above optionsATH_EEPROM_FIRMWARE +optionsATH_DEBUG_ALQ + # Boot off of the rootfs, as defined in the geom_map setup. optionsROOTDEVNAME=\"ufs:map/rootfs.uzip\" + +# This is required for the 2GHz LNAs on the AR9340 SoC. +# Without this the 2GHz radio is Quite Deaf. +device gpio +device gpioled ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355828 - head/sys/sys
Author: pfg Date: Mon Dec 16 23:55:30 2019 New Revision: 355828 URL: https://svnweb.freebsd.org/changeset/base/355828 Log: Double the size of ARG_MAX on LP64 platforms. As modern software keeps growing in size, we get requests to update the value of ARG_MAX in order to link the resulting object files. Other OSs have much higher values but Increasiong ARG_MAX has a multiplied effect on KVA, so just bumping this value is dangerous in some archs like ARM32 that can exhaust KVA rather easily. While it would be better to have a unique value for all archs, other OSs (Illumos in partidular) can have different ARG_MAX limits depending on the platform, For now we want to be really conservative so we are avoidng the change on ILP32 and in the alternative case we only double it since that seems to work well enough for recent Code Aster. I was planning to bump the _FreeBSD_version but it was bumped recently (r355798) so we can reuse the 1300068 value for this change. PR: 241710 MFC after:5 days Modified: head/sys/sys/syslimits.h Modified: head/sys/sys/syslimits.h == --- head/sys/sys/syslimits.hMon Dec 16 23:08:09 2019(r355827) +++ head/sys/sys/syslimits.hMon Dec 16 23:55:30 2019(r355828) @@ -48,7 +48,11 @@ * Do not add any new variables here. (See the comment at the end of * the file for why.) */ -#defineARG_MAX 262144 /* max bytes for an exec function */ +#ifndef __ILP32__ +#defineARG_MAX (2 * 256 * 1024) /* max bytes for an exec function */ +#else +#defineARG_MAX (256 * 1024) /* max bytes for KVA-starved archs */ +#endif #ifndef CHILD_MAX #defineCHILD_MAX 40 /* max simultaneous processes */ #endif ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355827 - head/sys/dev/pccbb
On Mon, Dec 16, 2019 at 4:08 PM Warner Losh wrote: > Author: imp > Date: Mon Dec 16 23:08:09 2019 > New Revision: 355827 > URL: https://svnweb.freebsd.org/changeset/base/355827 > > Log: > Add back accidentally dropped masking... > > - PCI_MASK_CONFIG(sc->dev, CBBR_BRIDGECTRL, > - & ~CBBM_BRIDGECTRL_INTR_IREQ_ISA_EN, 2); > > was accidentally dropped from r355822 in the refactor. Restore it since > 16-bit > cards may fail without it (some bridges autodetect this properly, so my > laptop > worked when I tested it). > > Noticed by: rpokala@ > > Modified: > head/sys/dev/pccbb/pccbb.c > > Modified: head/sys/dev/pccbb/pccbb.c > > == > --- head/sys/dev/pccbb/pccbb.c Mon Dec 16 22:05:03 2019(r355826) > +++ head/sys/dev/pccbb/pccbb.c Mon Dec 16 23:08:09 2019(r355827) > @@ -59,9 +59,6 @@ > > /* > * Driver for PCI to CardBus Bridge chips > - * and PCI to PCMCIA Bridge chips > - * and ISA to PCMCIA host adapters > - * and C Bus to PCMCIA host adapters > * > * References: > * TI Datasheets: > This was intentional, btw. I'd planned on doing it in a separate commit, but it wound up in this one. Not worth reverting and redoing, imho, so I won't. The cbb driver will just be for CardBus Bridges. There's a pcic driver, out of tree because it's broken and mostly irrelevant after the NIC purge, that will handle PCI and ISA to 16-bit PCMCIA bridges. And C Bus is no longer relevant because PC 98 support has been removed from FreeBSD (and the driver it would have been was relevant for only a few very old PC 98 laptops with custom NEC PCMCIA interface that's impossible to find docs for these days). Warner > @@ -273,6 +270,8 @@ cbb_enable_func_intr(struct cbb_softc *sc) > > reg = (exca_getb(>exca, EXCA_INTR) & ~EXCA_INTR_IRQ_MASK) | > EXCA_INTR_IRQ_NONE; > + PCI_MASK_CONFIG(sc->dev, CBBR_BRIDGECTRL, > + & ~CBBM_BRIDGECTRL_INTR_IREQ_ISA_EN, 2); > exca_putb(>exca, EXCA_INTR, reg); > } > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355819 - in head/sys: arm/arm arm64/arm64 i386/i386 mips/mips powerpc/powerpc riscv/riscv
> Author: jeff
> Date: Mon Dec 16 20:15:04 2019
> New Revision: 355819
> URL:
> https://svnweb.freebsd.org/changeset/base/355819
>
>
> Log:
> Repeat the spinlock_enter/exit pattern from amd64 on other architectures to
> fix an assert violation introduced in r355784. Without this spinlock_exit()
> may see owepreempt and switch before reducing the spinlock count. amd64
> had been optimized to do a single critical enter/exit regardless of the
> number of spinlocks which avoided the problem and this optimization had
> not been applied elsewhere.
>
> Reported by:emaste
> Suggested by: rlibby
> Discussed with: jhb, rlibby
> Tested by: manu (arm64)
>
> Modified:
> head/sys/arm/arm/machdep.c
> head/sys/arm64/arm64/machdep.c
> head/sys/i386/i386/machdep.c
> head/sys/mips/mips/machdep.c
> head/sys/powerpc/powerpc/machdep.c
> head/sys/riscv/riscv/machdep.c
It looks like sparc64 still has the old code structure:
>From /usr/src/sys/sparc64/sparc64/machdep.c . . .
void
spinlock_enter(void)
{
struct thread *td;
register_t pil;
td = curthread;
if (td->td_md.md_spinlock_count == 0) {
pil = rdpr(pil);
wrpr(pil, 0, PIL_TICK);
td->td_md.md_spinlock_count = 1;
td->td_md.md_saved_pil = pil;
} else
td->td_md.md_spinlock_count++;
critical_enter();
}
void
spinlock_exit(void)
{
struct thread *td;
register_t pil;
td = curthread;
critical_exit();
pil = td->td_md.md_saved_pil;
td->td_md.md_spinlock_count--;
if (td->td_md.md_spinlock_count == 0)
wrpr(pil, pil, 0);
}
(Not that I ever do anything with sparc64 machines.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355827 - head/sys/dev/pccbb
Author: imp Date: Mon Dec 16 23:08:09 2019 New Revision: 355827 URL: https://svnweb.freebsd.org/changeset/base/355827 Log: Add back accidentally dropped masking... - PCI_MASK_CONFIG(sc->dev, CBBR_BRIDGECTRL, - & ~CBBM_BRIDGECTRL_INTR_IREQ_ISA_EN, 2); was accidentally dropped from r355822 in the refactor. Restore it since 16-bit cards may fail without it (some bridges autodetect this properly, so my laptop worked when I tested it). Noticed by: rpokala@ Modified: head/sys/dev/pccbb/pccbb.c Modified: head/sys/dev/pccbb/pccbb.c == --- head/sys/dev/pccbb/pccbb.c Mon Dec 16 22:05:03 2019(r355826) +++ head/sys/dev/pccbb/pccbb.c Mon Dec 16 23:08:09 2019(r355827) @@ -59,9 +59,6 @@ /* * Driver for PCI to CardBus Bridge chips - * and PCI to PCMCIA Bridge chips - * and ISA to PCMCIA host adapters - * and C Bus to PCMCIA host adapters * * References: * TI Datasheets: @@ -273,6 +270,8 @@ cbb_enable_func_intr(struct cbb_softc *sc) reg = (exca_getb(>exca, EXCA_INTR) & ~EXCA_INTR_IRQ_MASK) | EXCA_INTR_IRQ_NONE; + PCI_MASK_CONFIG(sc->dev, CBBR_BRIDGECTRL, + & ~CBBM_BRIDGECTRL_INTR_IREQ_ISA_EN, 2); exca_putb(>exca, EXCA_INTR, reg); } ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355826 - head/lib/libxo head/lib/libxo/encoder/csv head/lib/libxo/libxo head/lib/libxo/tests head/lib/libxo/tests/encoder head/usr.bin/xo vendor/Juniper/libxo
Author: phil
Date: Mon Dec 16 22:05:03 2019
New Revision: 355826
URL: https://svnweb.freebsd.org/changeset/base/355826
Log:
Allow proper builds of libxo's CSV encoder:
- Move libxo.a build to subdirectory (lib/libxo/libxo/Makefile)
- Add .WAIT target to delay encoder build til after libxo
- Use FILES to install encoder library as csv.enc
- Update import script to put xo_config.h in new location
Added:
head/lib/libxo/libxo/
head/lib/libxo/libxo/Makefile (contents, props changed)
head/lib/libxo/libxo/xo_config.h
- copied unchanged from r355672, head/lib/libxo/xo_config.h
Deleted:
head/lib/libxo/xo_config.h
Modified:
head/lib/libxo/Makefile
head/lib/libxo/encoder/csv/Makefile
head/lib/libxo/tests/Makefile
head/lib/libxo/tests/encoder/Makefile
head/usr.bin/xo/Makefile
Changes in other areas also in this revision:
Modified:
vendor/Juniper/libxo/.svnignore
vendor/Juniper/libxo/import.sh
Directory Properties:
vendor/Juniper/libxo/ (props changed)
Modified: head/lib/libxo/Makefile
==
--- head/lib/libxo/Makefile Mon Dec 16 21:52:12 2019(r355825)
+++ head/lib/libxo/Makefile Mon Dec 16 22:05:03 2019(r355826)
@@ -1,119 +1,10 @@
# $FreeBSD$
-SHLIBDIR?= /lib
-
.include
-PACKAGE= runtime
-
-LIBXOSRC= ${SRCTOP}/contrib/libxo
-
-.PATH: ${LIBXOSRC}/libxo
-
-LIB= xo
-SHLIB_MAJOR=0
-
-SRCS= libxo.c xo_encoder.c xo_syslog.c
-
-CFLAGS+=-I${LIBXOSRC}/libxo -I${.CURDIR}
-CFLAGS+=-DXO_ENCODERDIR=\"/usr/lib/libxo/encoder\"
-
-INCS= xo.h xo_encoder.h
-INCSDIR=${INCLUDEDIR}/libxo
-
-LIBADD=util
-
-WARNS?= 5
-
-MAN+= libxo.3
-MAN+= xo_attr.3 \
- xo_create.3 \
- xo_emit.3 \
- xo_emit_err.3 \
- xo_err.3 \
- xo_error.3 \
- xo_finish.3 \
- xo_flush.3 \
- xo_message.3 \
- xo_no_setlocale.3 \
- xo_open_container.3 \
- xo_open_list.3 \
- xo_open_marker.3 \
- xo_parse_args.3 \
- xo_set_allocator.3 \
- xo_set_flags.3 \
- xo_set_info.3 \
- xo_set_options.3 \
- xo_set_style.3 \
- xo_set_syslog_enterprise_id.3 \
- xo_set_version.3 \
- xo_set_writer.3 \
- xo_syslog.3
-
-MAN+= xo_format.5
-
-MAN+= xo_options.7
-
-MLINKS=xo_attr.3 xo_attr_h.3 \
- xo_attr.3 xo_attr_hv.3 \
- xo_create.3 xo_create_to_file.3 \
- xo_create.3 xo_destroy.3 \
- xo_emit.3 xo_emit_h.3 \
- xo_emit.3 xo_emit_hv.3 \
- xo_emit_err.3 xo_emit_errc.3 \
- xo_emit_err.3 xo_emit_errx.3 \
- xo_emit_err.3 xo_emit_warn.3 \
- xo_emit_err.3 xo_emit_warnx.3 \
- xo_emit_err.3 xo_emit_warn_c.3 \
- xo_emit_err.3 xo_emit_warn_hc.3 \
- xo_err.3 xo_errc.3 \
- xo_err.3 xo_errx.3 \
- xo_err.3 xo_warn.3 \
- xo_err.3 xo_warnx.3 \
- xo_err.3 xo_warn_c.3 \
- xo_err.3 xo_warn_hc.3 \
- xo_finish.3 xo_finish_h.3 \
- xo_flush.3 xo_flush_h.3 \
- xo_message.3 xo_message_c.3 \
- xo_message.3 xo_message_hc.3 \
- xo_message.3 xo_message_hcv.3 \
- xo_open_container.3 xo_open_container_h.3 \
- xo_open_container.3 xo_open_container_hd.3 \
- xo_open_container.3 xo_open_container_d.3 \
- xo_open_container.3 xo_close_container.3 \
- xo_open_container.3 xo_close_container_h.3 \
- xo_open_container.3 xo_close_container_hd.3 \
- xo_open_container.3 xo_close_container_d.3 \
- xo_open_list.3 xo_open_list_h.3 \
- xo_open_list.3 xo_open_list_hd.3 \
- xo_open_list.3 xo_open_list_d.3 \
- xo_open_list.3 xo_open_instance.3 \
- xo_open_list.3 xo_open_instance_h.3 \
- xo_open_list.3 xo_open_instance_hd.3 \
- xo_open_list.3 xo_open_instance_d.3 \
- xo_open_list.3 xo_close_instance.3 \
- xo_open_list.3 xo_close_instance_h.3 \
- xo_open_list.3 xo_close_instance_hd.3 \
- xo_open_list.3 xo_close_instance_d.3 \
- xo_open_list.3 xo_close_list.3 \
- xo_open_list.3 xo_close_list_h.3 \
- xo_open_list.3 xo_close_list_hd.3 \
- xo_open_list.3 xo_close_list_d.3 \
- xo_open_marker.3 xo_open_marker_h.3 \
- xo_open_marker.3 xo_close_marker.3 \
- xo_open_marker.3 xo_close_marker_h.3 \
- xo_parse_args.3 xo_set_program.3 \
- xo_set_flags.3 xo_clear_flags.3 \
- xo_set_style.3 xo_set_style_name.3 \
- xo_set_version.3 xo_set_version_h.3 \
- xo_syslog.3 xo_close_log.3 \
- xo_syslog.3 xo_open_log.3 \
- xo_syslog.3 xo_set_logmask.3 \
- xo_syslog.3 xo_vsyslog.3
-
HAS_TESTS=
SUBDIR.${MK_TESTS}+= tests
-#SUBDIR = encoder
+SUBDIR = libxo .WAIT encoder
-.include
+.include
Modified: head/lib/libxo/encoder/csv/Makefile
==
--- head/lib/libxo/encoder/csv/Makefile Mon Dec 16 21:52:12 2019
(r355825)
+++
svn commit: r355825 - in head/stand/i386: common libi386
Author: imp
Date: Mon Dec 16 21:52:12 2019
New Revision: 355825
URL: https://svnweb.freebsd.org/changeset/base/355825
Log:
Use symbolic names for int13 calls
For all the INT13 calls, use symbolic names instead of magic numbers. This
makes
it easier to understand what the code is doing w/o a trip to google to find
what
these numbers mean.
Modified:
head/stand/i386/common/edd.h
head/stand/i386/libi386/biosdisk.c
Modified: head/stand/i386/common/edd.h
==
--- head/stand/i386/common/edd.hMon Dec 16 21:35:02 2019
(r355824)
+++ head/stand/i386/common/edd.hMon Dec 16 21:52:12 2019
(r355825)
@@ -107,4 +107,7 @@ struct edd_params_v4 {
#defineEDD_DEVICE_PATH_KEY 0xbedd
+#defineEDD_QUERY_MAGIC 0x55aa
+#defineEDD_INSTALLED 0xaa55
+
#endif /* !_EDD_H_ */
Modified: head/stand/i386/libi386/biosdisk.c
==
--- head/stand/i386/libi386/biosdisk.c Mon Dec 16 21:35:02 2019
(r355824)
+++ head/stand/i386/libi386/biosdisk.c Mon Dec 16 21:52:12 2019
(r355825)
@@ -64,6 +64,22 @@ __FBSDID("$FreeBSD$");
#defineACDMAJOR117
#defineCDMAJOR 15
+/*
+ * INT13 commands
+ */
+#defineCMD_RESET 0x
+#defineCMD_READ_CHS0x0200
+#defineCMD_WRITE_CHS 0x0300
+#defineCMD_READ_PARAM 0x0800
+#defineCMD_DRIVE_TYPE 0x1500
+#defineCMD_CHECK_EDD 0x4100
+#defineCMD_READ_LBA0x4200
+#defineCMD_WRITE_LBA 0x4300
+#defineCMD_EXT_PARAM 0x4800
+#defineCMD_CD_GET_STATUS 0x4b01
+
+#defineDISK_BIOS 0x13
+
#ifdef DISK_DEBUG
#defineDPRINTF(fmt, args...) printf("%s: " fmt "\n", __func__, ##
args)
#else
@@ -265,8 +281,8 @@ fd_count(void)
bd_reset_disk(drive);
v86.ctl = V86_FLAGS;
- v86.addr = 0x13;
- v86.eax = 0x1500;
+ v86.addr = DISK_BIOS;
+ v86.eax = CMD_DRIVE_TYPE;
v86.edx = drive;
v86int();
@@ -367,8 +383,8 @@ bc_add(int biosdev)
return (-1);
v86.ctl = V86_FLAGS;
-v86.addr = 0x13;
-v86.eax = 0x4b01;
+v86.addr = DISK_BIOS;
+v86.eax = CMD_CD_GET_STATUS;
v86.edx = biosdev;
v86.ds = VTOPSEG(_sp);
v86.esi = VTOPOFF(_sp);
@@ -422,14 +438,14 @@ bd_check_extensions(int unit)
/* Determine if we can use EDD with this device. */
v86.ctl = V86_FLAGS;
- v86.addr = 0x13;
- v86.eax = 0x4100;
+ v86.addr = DISK_BIOS;
+ v86.eax = CMD_CHECK_EDD;
v86.edx = unit;
- v86.ebx = 0x55aa;
+ v86.ebx = EDD_QUERY_MAGIC;
v86int();
if (V86_CY(v86.efl) || /* carry set */
- (v86.ebx & 0x) != 0xaa55) /* signature */
+ (v86.ebx & 0x) != EDD_INSTALLED) /* signature */
return (0);
/* extended disk access functions (AH=42h-44h,47h,48h) supported */
@@ -444,8 +460,8 @@ bd_reset_disk(int unit)
{
/* reset disk */
v86.ctl = V86_FLAGS;
- v86.addr = 0x13;
- v86.eax = 0;
+ v86.addr = DISK_BIOS;
+ v86.eax = CMD_RESET;
v86.edx = unit;
v86int();
}
@@ -458,8 +474,8 @@ bd_get_diskinfo_std(struct bdinfo *bd)
{
bzero(, sizeof(v86));
v86.ctl = V86_FLAGS;
- v86.addr = 0x13;
- v86.eax = 0x800;
+ v86.addr = DISK_BIOS;
+ v86.eax = CMD_READ_PARAM;
v86.edx = bd->bd_unit;
v86int();
@@ -493,8 +509,8 @@ bd_get_diskinfo_ext(struct bdinfo *bd)
bzero(, sizeof(params));
params.len = sizeof(params);
v86.ctl = V86_FLAGS;
- v86.addr = 0x13;
- v86.eax = 0x4800;
+ v86.addr = DISK_BIOS;
+ v86.eax = CMD_EXT_PARAM;
v86.edx = bd->bd_unit;
v86.ds = VTOPSEG();
v86.esi = VTOPOFF();
@@ -560,8 +576,8 @@ bd_int13probe(bdinfo_t *bd)
/* Get disk type */
v86.ctl = V86_FLAGS;
- v86.addr = 0x13;
- v86.eax = 0x1500;
+ v86.addr = DISK_BIOS;
+ v86.eax = CMD_DRIVE_TYPE;
v86.edx = bd->bd_unit;
v86int();
if (V86_CY(v86.efl) || (v86.eax & 0x300) == 0)
@@ -1076,12 +1092,11 @@ bd_edd_io(bdinfo_t *bd, daddr_t dblk, int blks, caddr_
packet.seg = VTOPSEG(dest);
packet.lba = dblk;
v86.ctl = V86_FLAGS;
- v86.addr = 0x13;
- /* Should we Write with verify ?? 0x4302 ? */
+ v86.addr = DISK_BIOS;
if (dowrite == BD_WR)
- v86.eax = 0x4300;
+ v86.eax = CMD_WRITE_LBA; /* maybe Write with verify 0x4302? */
else
- v86.eax = 0x4200;
+ v86.eax =
svn commit: r355822 - in head/sys: conf dev/pccbb modules/cbb
Author: imp
Date: Mon Dec 16 21:34:51 2019
New Revision: 355822
URL: https://svnweb.freebsd.org/changeset/base/355822
Log:
We'll never have multiple slots a cardbus bridge. So, replace exca
array with a singleton.
Also, pccbb isa attachment is never going to happen, do disconnect it from the
build (will delete this in future commit). It would need to be updated as
well,
but since this code is effectively dead code, remove it from the build
instead.
Modified:
head/sys/conf/files
head/sys/dev/pccbb/pccbb.c
head/sys/dev/pccbb/pccbb_pci.c
head/sys/dev/pccbb/pccbbvar.h
head/sys/modules/cbb/Makefile
Modified: head/sys/conf/files
==
--- head/sys/conf/files Mon Dec 16 21:06:24 2019(r355821)
+++ head/sys/conf/files Mon Dec 16 21:34:51 2019(r355822)
@@ -2552,7 +2552,6 @@ dev/pccard/pccard_cis_quirks.coptional pccard
dev/pccard/pccard_device.c optional pccard
dev/pccard/power_if.m standard
dev/pccbb/pccbb.c optional cbb
-dev/pccbb/pccbb_isa.c optional cbb isa
dev/pccbb/pccbb_pci.c optional cbb pci
dev/pcf/pcf.c optional pcf
dev/pci/fixup_pci.coptional pci
Modified: head/sys/dev/pccbb/pccbb.c
==
--- head/sys/dev/pccbb/pccbb.c Mon Dec 16 21:06:24 2019(r355821)
+++ head/sys/dev/pccbb/pccbb.c Mon Dec 16 21:34:51 2019(r355822)
@@ -253,9 +253,9 @@ cbb_disable_func_intr(struct cbb_softc *sc)
#if 0
uint8_t reg;
- reg = (exca_getb(>exca[0], EXCA_INTR) & ~EXCA_INTR_IRQ_MASK) |
+ reg = (exca_getb(>exca, EXCA_INTR) & ~EXCA_INTR_IRQ_MASK) |
EXCA_INTR_IRQ_RESERVED1;
- exca_putb(>exca[0], EXCA_INTR, reg);
+ exca_putb(>exca, EXCA_INTR, reg);
#endif
}
@@ -271,11 +271,9 @@ cbb_enable_func_intr(struct cbb_softc *sc)
{
uint8_t reg;
- reg = (exca_getb(>exca[0], EXCA_INTR) & ~EXCA_INTR_IRQ_MASK) |
+ reg = (exca_getb(>exca, EXCA_INTR) & ~EXCA_INTR_IRQ_MASK) |
EXCA_INTR_IRQ_NONE;
- exca_putb(>exca[0], EXCA_INTR, reg);
- PCI_MASK_CONFIG(sc->dev, CBBR_BRIDGECTRL,
- & ~CBBM_BRIDGECTRL_INTR_IREQ_ISA_EN, 2);
+ exca_putb(>exca, EXCA_INTR, reg);
}
int
@@ -322,7 +320,7 @@ cbb_detach(device_t brdev)
cbb_set(sc, CBB_SOCKET_MASK, 0);
/* reset 16-bit pcmcia bus */
- exca_clrb(>exca[0], EXCA_INTR, EXCA_INTR_RESET);
+ exca_clrb(>exca, EXCA_INTR, EXCA_INTR_RESET);
/* turn off power */
cbb_power(brdev, CARD_OFF);
@@ -442,7 +440,7 @@ cbb_child_detached(device_t brdev, device_t child)
struct cbb_softc *sc = device_get_softc(brdev);
/* I'm not sure we even need this */
- if (child != sc->cbdev && child != sc->exca[0].pccarddev)
+ if (child != sc->cbdev && child != sc->exca.pccarddev)
device_printf(brdev, "Unknown child detached: %s\n",
device_get_nameunit(child));
}
@@ -549,9 +547,9 @@ cbb_insert(struct cbb_softc *sc)
sockevent, sockstate));
if (sockstate & CBB_STATE_R2_CARD) {
- if (device_is_attached(sc->exca[0].pccarddev)) {
+ if (device_is_attached(sc->exca.pccarddev)) {
sc->flags |= CBB_16BIT_CARD;
- exca_insert(>exca[0]);
+ exca_insert(>exca);
} else {
device_printf(sc->dev,
"16-bit card inserted, but no pccard bus.\n");
@@ -578,7 +576,7 @@ cbb_removal(struct cbb_softc *sc)
{
sc->cardok = 0;
if (sc->flags & CBB_16BIT_CARD) {
- exca_removal(>exca[0]);
+ exca_removal(>exca);
} else {
if (device_is_attached(sc->cbdev))
CARD_DETACH_CARD(sc->cbdev);
@@ -708,8 +706,8 @@ cbb_o2micro_power_hack(struct cbb_softc *sc)
* keyboard controller's interrupts being suppressed occurred when
* we did this.
*/
- reg = exca_getb(>exca[0], EXCA_INTR);
- exca_putb(>exca[0], EXCA_INTR, (reg & 0xf0) | 1);
+ reg = exca_getb(>exca, EXCA_INTR);
+ exca_putb(>exca, EXCA_INTR, (reg & 0xf0) | 1);
return (reg);
}
@@ -721,7 +719,7 @@ cbb_o2micro_power_hack(struct cbb_softc *sc)
static void
cbb_o2micro_power_hack2(struct cbb_softc *sc, uint8_t reg)
{
- exca_putb(>exca[0], EXCA_INTR, reg);
+ exca_putb(>exca, EXCA_INTR, reg);
}
int
@@ -921,7 +919,7 @@ cbb_do_power(device_t brdev)
uint32_t status;
/* Don't enable OE (output enable) until power stable */
- exca_clrb(>exca[0], EXCA_PWRCTL, EXCA_PWRCTL_OE);
+ exca_clrb(>exca, EXCA_PWRCTL, EXCA_PWRCTL_OE);
voltage = cbb_detect_voltage(brdev);
curpwr = cbb_current_voltage(brdev);
@@ -1312,7 +1310,7 @@
svn commit: r355823 - in head/sys/dev: exca pccbb
Author: imp
Date: Mon Dec 16 21:34:57 2019
New Revision: 355823
URL: https://svnweb.freebsd.org/changeset/base/355823
Log:
Add slot number ivar to return which slot number the child is attached to.
This will always be 0 for pccbb, but may be non-zero for other kinds of
bridges,
should they show up in the tree. Make querying it generic.
Modified:
head/sys/dev/exca/excavar.h
head/sys/dev/pccbb/pccbb.c
Modified: head/sys/dev/exca/excavar.h
==
--- head/sys/dev/exca/excavar.h Mon Dec 16 21:34:51 2019(r355822)
+++ head/sys/dev/exca/excavar.h Mon Dec 16 21:34:57 2019(r355823)
@@ -151,4 +151,17 @@ exca_clrb(struct exca_softc *sc, int reg, uint8_t mask
exca_putb(sc, reg, exca_getb(sc, reg) & ~mask);
}
+enum {
+ EXCA_IVAR_SLOT = 100,
+};
+
+#define EXCA_ACCESSOR(A, B, T) \
+static inline int \
+exca_get_ ## A(device_t dev, T *t) \
+{ \
+ return BUS_READ_IVAR(device_get_parent(dev), dev, \
+ EXCA_IVAR_ ## B, (uintptr_t *) t); \
+}
+
+EXCA_ACCESSOR(slot,SLOT, uint32_t)
#endif /* !_SYS_DEV_EXCA_EXCAVAR_H */
Modified: head/sys/dev/pccbb/pccbb.c
==
--- head/sys/dev/pccbb/pccbb.c Mon Dec 16 21:34:51 2019(r355822)
+++ head/sys/dev/pccbb/pccbb.c Mon Dec 16 21:34:57 2019(r355823)
@@ -1565,6 +1565,9 @@ cbb_read_ivar(device_t brdev, device_t child, int whic
case PCIB_IVAR_BUS:
*result = sc->bus.sec;
return (0);
+ case EXCA_IVAR_SLOT:
+ *result = 0;
+ return (0);
}
return (ENOENT);
}
@@ -1577,6 +1580,8 @@ cbb_write_ivar(device_t brdev, device_t child, int whi
case PCIB_IVAR_DOMAIN:
return (EINVAL);
case PCIB_IVAR_BUS:
+ return (EINVAL);
+ case EXCA_IVAR_SLOT:
return (EINVAL);
}
return (ENOENT);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355824 - in head/sys/dev: exca pccbb
Author: imp Date: Mon Dec 16 21:35:02 2019 New Revision: 355824 URL: https://svnweb.freebsd.org/changeset/base/355824 Log: Move attachment of pccard children into exca library. Attach the cardbus and pccard children before the sysctls are added rather than after. Modified: head/sys/dev/exca/exca.c head/sys/dev/pccbb/pccbb_pci.c Modified: head/sys/dev/exca/exca.c == --- head/sys/dev/exca/exca.cMon Dec 16 21:34:57 2019(r355823) +++ head/sys/dev/exca/exca.cMon Dec 16 21:35:02 2019(r355824) @@ -646,6 +646,11 @@ exca_init(struct exca_softc *sc, device_t dev, sc->flags = 0; sc->getb = exca_mem_getb; sc->putb = exca_mem_putb; + sc->pccarddev = device_add_child(dev, "pccard", -1); + if (sc->pccarddev == NULL) + DEVPRINTF(brdev, "WARNING: cannot add pccard bus.\n"); + else if (device_probe_and_attach(sc->pccarddev) != 0) + DEVPRINTF(brdev, "WARNING: cannot attach pccard bus.\n"); } /* @@ -742,6 +747,8 @@ exca_valid_slot(struct exca_softc *exca) * Intel i82365sl-DF step or maybe a vlsi 82c146 * we detected the vlsi case earlier, so if the controller * isn't set, we know it is a i82365sl step D. +* Except we didn't -- this is a regression but VLSI +* controllers are super hard to find these days for testing. */ exca->chipset = EXCA_I82365SL_DF; break; Modified: head/sys/dev/pccbb/pccbb_pci.c == --- head/sys/dev/pccbb/pccbb_pci.c Mon Dec 16 21:34:57 2019 (r355823) +++ head/sys/dev/pccbb/pccbb_pci.c Mon Dec 16 21:35:02 2019 (r355824) @@ -317,6 +317,13 @@ cbb_pci_attach(device_t brdev) rman_get_start(sc->base_res))); } + /* attach children */ + sc->cbdev = device_add_child(brdev, "cardbus", -1); + if (sc->cbdev == NULL) + DEVPRINTF((brdev, "WARNING: cannot add cardbus bus.\n")); + else if (device_probe_and_attach(sc->cbdev) != 0) + DEVPRINTF((brdev, "WARNING: cannot attach cardbus bus!\n")); + sc->bst = rman_get_bustag(sc->base_res); sc->bsh = rman_get_bushandle(sc->base_res); exca_init(>exca, brdev, sc->bst, sc->bsh, CBB_EXCA_OFFSET); @@ -372,19 +379,6 @@ cbb_pci_attach(device_t brdev) pci_write_config(brdev, PCIR_SUBBUS_2, sc->bus.sub, 1); } #endif - - /* attach children */ - sc->cbdev = device_add_child(brdev, "cardbus", -1); - if (sc->cbdev == NULL) - DEVPRINTF((brdev, "WARNING: cannot add cardbus bus.\n")); - else if (device_probe_and_attach(sc->cbdev) != 0) - DEVPRINTF((brdev, "WARNING: cannot attach cardbus bus!\n")); - - sc->exca.pccarddev = device_add_child(brdev, "pccard", -1); - if (sc->exca.pccarddev == NULL) - DEVPRINTF((brdev, "WARNING: cannot add pccard bus.\n")); - else if (device_probe_and_attach(sc->exca.pccarddev) != 0) - DEVPRINTF((brdev, "WARNING: cannot attach pccard bus.\n")); /* Map and establish the interrupt. */ rid = 0; ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355821 - in head: sbin/geom usr.sbin/ppp
Author: imp
Date: Mon Dec 16 21:06:24 2019
New Revision: 355821
URL: https://svnweb.freebsd.org/changeset/base/355821
Log:
Remove all the RELEASE_CRUNCH defines, they are useless.
RELEASE_CRUNCH has been broken for a very long time. Remove the
last remants from the tree.
Modified:
head/sbin/geom/Makefile
head/usr.sbin/ppp/Makefile
Modified: head/sbin/geom/Makefile
==
--- head/sbin/geom/Makefile Mon Dec 16 20:15:44 2019(r355820)
+++ head/sbin/geom/Makefile Mon Dec 16 21:06:24 2019(r355821)
@@ -13,7 +13,7 @@ CFLAGS+= -DGEOM_CLASS_DIR=\"${GEOM_CLASS_DIR}\"
LIBADD=geom util
-.if defined(RESCUE) || defined(RELEASE_CRUNCH)
+.if defined(RESCUE)
.PATH: ${SRCTOP}/lib/geom/part \
${SRCTOP}/lib/geom/label
Modified: head/usr.sbin/ppp/Makefile
==
--- head/usr.sbin/ppp/Makefile Mon Dec 16 20:15:44 2019(r355820)
+++ head/usr.sbin/ppp/Makefile Mon Dec 16 21:06:24 2019(r355821)
@@ -11,14 +11,6 @@ SRCS=acf.c arp.c async.c auth.c bundle.c cbcp.c ccp.c
proto.c route.c server.c sig.c slcompress.c sync.c systems.c tcp.c \
tcpmss.c throughput.c timer.c tty.c tun.c udp.c vjcomp.c
WARNS?=3
-.if defined(RELEASE_CRUNCH)
-PPP_NO_DES=
-PPP_NO_KLDLOAD=
-PPP_NO_NAT=
-PPP_NO_PAM=
-PPP_NO_RADIUS=
-PPP_NO_SUID=
-.endif
CONFS= ppp.conf
CONFSDIR= ${CONFDIR}/ppp
CONFSMODE= 600
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355818 - in head: share/man/man4 sys/amd64/linux sys/amd64/linux32 sys/arm64/linux sys/compat/linux sys/i386/linux
> On Dec 16, 2019, at 12:07, Edward Tomasz Napierala wrote: > > Author: trasz > Date: Mon Dec 16 20:07:04 2019 > New Revision: 355818 > URL: https://svnweb.freebsd.org/changeset/base/355818 > > Log: > Add compat.linux.emul_path, so it can be set to something other > than "/compat/linux". Useful when you have several compat directories > with different Linux versions and you don't want to clash with files > installed by linux-c7 packages. Hi Edward! Great feature :).. i was wondering if it made sense to implement this sysctl as a per-jail setting so one jail could have one setting and another have another setting? Arguably, one could just leave the default, but it’s a just thought I had when reading your commit message. Thank you :)! -Enji ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355820 - in head: share/man/man4 sys/compat/linux
Author: trasz Date: Mon Dec 16 20:15:44 2019 New Revision: 355820 URL: https://svnweb.freebsd.org/changeset/base/355820 Log: Add a hack to make ^T work for Linux binaries, enabled with 'compat.linux.preserve_vstatus=1' sysctl. MFC after:2 weeks Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D21967 Modified: head/share/man/man4/linux.4 head/sys/compat/linux/linux_ioctl.c head/sys/compat/linux/linux_ioctl.h head/sys/compat/linux/linux_mib.c head/sys/compat/linux/linux_mib.h Modified: head/share/man/man4/linux.4 == --- head/share/man/man4/linux.4 Mon Dec 16 20:15:04 2019(r355819) +++ head/share/man/man4/linux.4 Mon Dec 16 20:15:44 2019(r355820) @@ -109,6 +109,14 @@ Recent versions of GNU libc are known to use different on the value of this sysctl. .It Va compat.linux.oss_version Linux Open Sound System version. +.It Va compat.linux.preserve_vstatus +When set to 1, it prevents Linux applications from resetting the +.Xr termios 4 +VSTATUS setting. +From a user perspective, this makes +.Va SIGINFO +work for Linux executables. +Defaults to 0. .Sh FILES .Bl -tag -width /compat/linux/dev/shm -compact .It Pa /compat/linux Modified: head/sys/compat/linux/linux_ioctl.c == --- head/sys/compat/linux/linux_ioctl.c Mon Dec 16 20:15:04 2019 (r355819) +++ head/sys/compat/linux/linux_ioctl.c Mon Dec 16 20:15:44 2019 (r355820) @@ -500,6 +500,8 @@ bsd_to_linux_termios(struct termios *bios, struct linu lios->c_cc[LINUX_VDISCARD] = bios->c_cc[VDISCARD]; lios->c_cc[LINUX_VWERASE] = bios->c_cc[VWERASE]; lios->c_cc[LINUX_VLNEXT] = bios->c_cc[VLNEXT]; + if (linux_preserve_vstatus) + lios->c_cc[LINUX_VSTATUS] = bios->c_cc[VSTATUS]; for (i=0; ic_cc[VDISCARD] = lios->c_cc[LINUX_VDISCARD]; bios->c_cc[VWERASE] = lios->c_cc[LINUX_VWERASE]; bios->c_cc[VLNEXT] = lios->c_cc[LINUX_VLNEXT]; + if (linux_preserve_vstatus) + bios->c_cc[VSTATUS] = lios->c_cc[LINUX_VSTATUS]; for (i=0; i= LINUX_KERNVER_2006000) +extern int linux_preserve_vstatus; + #endif /* _LINUX_MIB_H_ */ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355819 - in head/sys: arm/arm arm64/arm64 i386/i386 mips/mips powerpc/powerpc riscv/riscv
Author: jeff
Date: Mon Dec 16 20:15:04 2019
New Revision: 355819
URL: https://svnweb.freebsd.org/changeset/base/355819
Log:
Repeat the spinlock_enter/exit pattern from amd64 on other architectures to
fix an assert violation introduced in r355784. Without this spinlock_exit()
may see owepreempt and switch before reducing the spinlock count. amd64
had been optimized to do a single critical enter/exit regardless of the
number of spinlocks which avoided the problem and this optimization had
not been applied elsewhere.
Reported by: emaste
Suggested by: rlibby
Discussed with: jhb, rlibby
Tested by:manu (arm64)
Modified:
head/sys/arm/arm/machdep.c
head/sys/arm64/arm64/machdep.c
head/sys/i386/i386/machdep.c
head/sys/mips/mips/machdep.c
head/sys/powerpc/powerpc/machdep.c
head/sys/riscv/riscv/machdep.c
Modified: head/sys/arm/arm/machdep.c
==
--- head/sys/arm/arm/machdep.c Mon Dec 16 20:07:04 2019(r355818)
+++ head/sys/arm/arm/machdep.c Mon Dec 16 20:15:04 2019(r355819)
@@ -389,9 +389,9 @@ spinlock_enter(void)
cspr = disable_interrupts(PSR_I | PSR_F);
td->td_md.md_spinlock_count = 1;
td->td_md.md_saved_cspr = cspr;
+ critical_enter();
} else
td->td_md.md_spinlock_count++;
- critical_enter();
}
void
@@ -401,11 +401,12 @@ spinlock_exit(void)
register_t cspr;
td = curthread;
- critical_exit();
cspr = td->td_md.md_saved_cspr;
td->td_md.md_spinlock_count--;
- if (td->td_md.md_spinlock_count == 0)
+ if (td->td_md.md_spinlock_count == 0) {
+ critical_exit();
restore_interrupts(cspr);
+ }
}
/*
Modified: head/sys/arm64/arm64/machdep.c
==
--- head/sys/arm64/arm64/machdep.c Mon Dec 16 20:07:04 2019
(r355818)
+++ head/sys/arm64/arm64/machdep.c Mon Dec 16 20:15:04 2019
(r355819)
@@ -635,9 +635,9 @@ spinlock_enter(void)
daif = intr_disable();
td->td_md.md_spinlock_count = 1;
td->td_md.md_saved_daif = daif;
+ critical_enter();
} else
td->td_md.md_spinlock_count++;
- critical_enter();
}
void
@@ -647,11 +647,12 @@ spinlock_exit(void)
register_t daif;
td = curthread;
- critical_exit();
daif = td->td_md.md_saved_daif;
td->td_md.md_spinlock_count--;
- if (td->td_md.md_spinlock_count == 0)
+ if (td->td_md.md_spinlock_count == 0) {
+ critical_exit();
intr_restore(daif);
+ }
}
#ifndef_SYS_SYSPROTO_H_
Modified: head/sys/i386/i386/machdep.c
==
--- head/sys/i386/i386/machdep.cMon Dec 16 20:07:04 2019
(r355818)
+++ head/sys/i386/i386/machdep.cMon Dec 16 20:15:04 2019
(r355819)
@@ -2679,9 +2679,9 @@ spinlock_enter(void)
flags = intr_disable();
td->td_md.md_spinlock_count = 1;
td->td_md.md_saved_flags = flags;
+ critical_enter();
} else
td->td_md.md_spinlock_count++;
- critical_enter();
}
void
@@ -2691,11 +2691,12 @@ spinlock_exit(void)
register_t flags;
td = curthread;
- critical_exit();
flags = td->td_md.md_saved_flags;
td->td_md.md_spinlock_count--;
- if (td->td_md.md_spinlock_count == 0)
+ if (td->td_md.md_spinlock_count == 0) {
+ critical_exit();
intr_restore(flags);
+ }
}
#if defined(I586_CPU) && !defined(NO_F00F_HACK)
Modified: head/sys/mips/mips/machdep.c
==
--- head/sys/mips/mips/machdep.cMon Dec 16 20:07:04 2019
(r355818)
+++ head/sys/mips/mips/machdep.cMon Dec 16 20:15:04 2019
(r355819)
@@ -516,9 +516,9 @@ spinlock_enter(void)
intr = intr_disable();
td->td_md.md_spinlock_count = 1;
td->td_md.md_saved_intr = intr;
+ critical_enter();
} else
td->td_md.md_spinlock_count++;
- critical_enter();
}
void
@@ -528,11 +528,12 @@ spinlock_exit(void)
register_t intr;
td = curthread;
- critical_exit();
intr = td->td_md.md_saved_intr;
td->td_md.md_spinlock_count--;
- if (td->td_md.md_spinlock_count == 0)
+ if (td->td_md.md_spinlock_count == 0) {
+ critical_exit();
intr_restore(intr);
+ }
}
/*
Modified: head/sys/powerpc/powerpc/machdep.c
==
---
svn commit: r355818 - in head: share/man/man4 sys/amd64/linux sys/amd64/linux32 sys/arm64/linux sys/compat/linux sys/i386/linux
Author: trasz
Date: Mon Dec 16 20:07:04 2019
New Revision: 355818
URL: https://svnweb.freebsd.org/changeset/base/355818
Log:
Add compat.linux.emul_path, so it can be set to something other
than "/compat/linux". Useful when you have several compat directories
with different Linux versions and you don't want to clash with files
installed by linux-c7 packages.
Reviewed by: bcr (manpages)
MFC after:2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision:https://reviews.freebsd.org/D22574
Modified:
head/share/man/man4/linux.4
head/sys/amd64/linux/linux_sysvec.c
head/sys/amd64/linux32/linux32_sysvec.c
head/sys/arm64/linux/linux_sysvec.c
head/sys/compat/linux/linux_util.c
head/sys/compat/linux/linux_util.h
head/sys/i386/linux/linux_sysvec.c
Modified: head/share/man/man4/linux.4
==
--- head/share/man/man4/linux.4 Mon Dec 16 19:16:26 2019(r355817)
+++ head/share/man/man4/linux.4 Mon Dec 16 20:07:04 2019(r355818)
@@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd November 13, 2019
+.Dd December 16, 2019
.Dt LINUX 4
.Os
.Sh NAME
@@ -95,6 +95,10 @@ variables and
.Xr loader 8
tunables:
.Bl -tag -width indent
+.It Va compat.linux.emul_path
+Path to the Linux run-time environment.
+Defaults to
+.Pa /compat/linux .
.It Va compat.linux.osname
Linux kernel operating system name.
.It Va compat.linux.osrelease
Modified: head/sys/amd64/linux/linux_sysvec.c
==
--- head/sys/amd64/linux/linux_sysvec.c Mon Dec 16 19:16:26 2019
(r355817)
+++ head/sys/amd64/linux/linux_sysvec.c Mon Dec 16 20:07:04 2019
(r355818)
@@ -836,7 +836,7 @@ static Elf64_Brandinfo linux_glibc2brand = {
.brand = ELFOSABI_LINUX,
.machine= EM_X86_64,
.compat_3_brand = "Linux",
- .emul_path = "/compat/linux",
+ .emul_path = linux_emul_path,
.interp_path= "/lib64/ld-linux-x86-64.so.2",
.sysvec = _linux_sysvec,
.interp_newpath = NULL,
@@ -848,7 +848,7 @@ static Elf64_Brandinfo linux_glibc2brandshort = {
.brand = ELFOSABI_LINUX,
.machine= EM_X86_64,
.compat_3_brand = "Linux",
- .emul_path = "/compat/linux",
+ .emul_path = linux_emul_path,
.interp_path= "/lib64/ld-linux.so.2",
.sysvec = _linux_sysvec,
.interp_newpath = NULL,
@@ -860,7 +860,7 @@ static Elf64_Brandinfo linux_muslbrand = {
.brand = ELFOSABI_LINUX,
.machine= EM_X86_64,
.compat_3_brand = "Linux",
- .emul_path = "/compat/linux",
+ .emul_path = linux_emul_path,
.interp_path= "/lib/ld-musl-x86_64.so.1",
.sysvec = _linux_sysvec,
.interp_newpath = NULL,
Modified: head/sys/amd64/linux32/linux32_sysvec.c
==
--- head/sys/amd64/linux32/linux32_sysvec.c Mon Dec 16 19:16:26 2019
(r355817)
+++ head/sys/amd64/linux32/linux32_sysvec.c Mon Dec 16 20:07:04 2019
(r355818)
@@ -992,7 +992,7 @@ static Elf32_Brandinfo linux_brand = {
.brand = ELFOSABI_LINUX,
.machine= EM_386,
.compat_3_brand = "Linux",
- .emul_path = "/compat/linux",
+ .emul_path = linux_emul_path,
.interp_path= "/lib/ld-linux.so.1",
.sysvec = _linux_sysvec,
.interp_newpath = NULL,
@@ -1004,7 +1004,7 @@ static Elf32_Brandinfo linux_glibc2brand = {
.brand = ELFOSABI_LINUX,
.machine= EM_386,
.compat_3_brand = "Linux",
- .emul_path = "/compat/linux",
+ .emul_path = linux_emul_path,
.interp_path= "/lib/ld-linux.so.2",
.sysvec = _linux_sysvec,
.interp_newpath = NULL,
@@ -1016,7 +1016,7 @@ static Elf32_Brandinfo linux_muslbrand = {
.brand = ELFOSABI_LINUX,
.machine= EM_386,
.compat_3_brand = "Linux",
- .emul_path = "/compat/linux",
+ .emul_path = linux_emul_path,
.interp_path= "/lib/ld-musl-i386.so.1",
.sysvec = _linux_sysvec,
.interp_newpath = NULL,
Modified: head/sys/arm64/linux/linux_sysvec.c
==
--- head/sys/arm64/linux/linux_sysvec.c Mon Dec 16 19:16:26 2019
(r355817)
+++ head/sys/arm64/linux/linux_sysvec.c Mon Dec 16 20:07:04 2019
(r355818)
@@ -54,6 +54,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
MODULE_VERSION(linux64elf, 1);
@@ -494,7 +495,7 @@ static Elf64_Brandinfo linux_glibc2brand = {
.brand = ELFOSABI_LINUX,
.machine= EM_AARCH64,
.compat_3_brand =
Re: svn commit: r355784 - in head/sys: compat/linuxkpi/common/src dev/dpaa kern mips/nlm sys
The entire thing reads like a bug -- for each platform critical_exit
can venture into mi_switch with interrupts disabled. On amd64 it just
happens to do it after the count was updated, but still before they
got-reenabled. Other platform also do critical enter/exit dance on
each call instead of just on the 0<->1 transition of
md_spinlock_count.
iow each platform should be probably doing something like this instead:
diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
index 7aadd86e3cd6..c90fe8ef961d 100644
--- a/sys/amd64/amd64/machdep.c
+++ b/sys/amd64/amd64/machdep.c
@@ -1991,10 +1991,10 @@ spinlock_enter(void)
td = curthread;
if (td->td_md.md_spinlock_count == 0) {
+ critical_enter();
flags = intr_disable();
td->td_md.md_spinlock_count = 1;
td->td_md.md_saved_flags = flags;
- critical_enter();
} else
td->td_md.md_spinlock_count++;
}
@@ -2009,8 +2009,8 @@ spinlock_exit(void)
flags = td->td_md.md_saved_flags;
td->td_md.md_spinlock_count--;
if (td->td_md.md_spinlock_count == 0) {
- critical_exit();
intr_restore(flags);
+ critical_exit();
}
}
On 12/16/19, Jeff Roberson wrote:
> On Mon, 16 Dec 2019, Ryan Libby wrote:
>
>> On Mon, Dec 16, 2019 at 7:30 AM Ed Maste wrote:
>>>
>>> On Sun, 15 Dec 2019 at 16:27, Jeff Roberson wrote:
Author: jeff
Date: Sun Dec 15 21:26:50 2019
New Revision: 355784
URL: https://svnweb.freebsd.org/changeset/base/355784
Log:
schedlock 4/4
>>>
>>> FYI i386, arm, arm64, riscv fail to boot now, with "panic: invalid count
>>> 2"
>>>
>>> Boot logs:
>>> i386: https://ci.freebsd.org/job/FreeBSD-head-i386-test/7797/console
>>> arm:
>>> https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-beaglebone-test/1317/artifact/device_tests/beaglebone.boot.log
>>> arm64:
>>> https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-pinea64-test/1194/artifact/device_tests/pinea64.boot.log
>>> riscv:
>>> https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-pinea64-test/1194/artifact/device_tests/pinea64.boot.log
>>>
>>> arm64 is:
>>>
>>> panic: invalid count 2
>>> cpuid = 0
>>> time = 1
>>> KDB: stack backtrace:
>>> db_trace_self() at db_trace_self_wrapper+0x28
>>> pc = 0x007359ec lr = 0x00106744
>>> sp = 0x56b063c0 fp = 0x56b065d0
>>>
>>> db_trace_self_wrapper() at vpanic+0x18c
>>> pc = 0x00106744 lr = 0x00408128
>>> sp = 0x56b065e0 fp = 0x56b06690
>>>
>>> vpanic() at panic+0x44
>>> pc = 0x00408128 lr = 0x00407ed8
>>> sp = 0x56b066a0 fp = 0x56b06720
>>>
>>> panic() at sched_switch+0x81c
>>> pc = 0x00407ed8 lr = 0x00434264
>>> sp = 0x56b06730 fp = 0x56b06810
>>>
>>> sched_switch() at mi_switch+0x170
>>> pc = 0x00434264 lr = 0x00413690
>>> sp = 0x56b06820 fp = 0x56b06840
>>>
>>> mi_switch() at cpu_idle+0xc8
>>> pc = 0x00413690 lr = 0x007400a0
>>> sp = 0x56b06850 fp = 0x56b06860
>>>
>>> cpu_idle() at sched_idletd+0x380
>>> pc = 0x007400a0 lr = 0x00436a90
>>> sp = 0x56b06870 fp = 0x56b06940
>>>
>>> sched_idletd() at fork_exit+0x7c
>>> pc = 0x00436a90 lr = 0x003c7ba4
>>> sp = 0x56b06950 fp = 0x56b06980
>>>
>>> fork_exit() at fork_trampoline+0x10
>>> pc = 0x003c7ba4 lr = 0x007521ac
>>> sp = 0x56b06990 fp = 0x
>>>
>>> KDB: enter: panic
>>> [ thread pid 11 tid 13 ]
>>> Stopped at 0
>>> db>
>>
>> It looks like amd64 vs i386, riscv, etc are using different motifs in
>> spinlock_exit(). Perhaps we just need to rearrange them to drop the
>> spinlock count before critical_exit(), like in amd64.
>
> It took me a moment to see why but I believe you are right. Interrupts
> being disabled would prevent a local preemption with the flags out of sync
> but critical_exit() might have owepreempt set so we will switch before
> updating the count.
>
> Jeff
>
>>
>> Ryan
>>
>
--
Mateusz Guzik
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355817 - in head/sys/cam: ata scsi
Author: imp
Date: Mon Dec 16 19:16:26 2019
New Revision: 355817
URL: https://svnweb.freebsd.org/changeset/base/355817
Log:
Revert r355813
It was extracted from a larger tree and is incomplete. Will resubmit after
reworking.
Modified:
head/sys/cam/ata/ata_da.c
head/sys/cam/scsi/scsi_da.c
Modified: head/sys/cam/ata/ata_da.c
==
--- head/sys/cam/ata/ata_da.c Mon Dec 16 19:08:49 2019(r355816)
+++ head/sys/cam/ata/ata_da.c Mon Dec 16 19:16:26 2019(r355817)
@@ -858,10 +858,6 @@ static voidadaresume(void *arg);
#defineADA_DEFAULT_WRITE_CACHE 1
#endif
-#ifndefADA_DEFAULT_MAX_DELETE
-#defineADA_DEFAULT_MAX_DELETE (1 * 1024 * 1024 * 1024)/* 1GB
max trim by default */
-#endif
-
#defineADA_RA (softc->read_ahead >= 0 ? \
softc->read_ahead : ada_read_ahead)
#defineADA_WC (softc->write_cache >= 0 ? \
@@ -882,7 +878,6 @@ static int ada_spindown_shutdown = ADA_DEFAULT_SPINDOW
static int ada_spindown_suspend = ADA_DEFAULT_SPINDOWN_SUSPEND;
static int ada_read_ahead = ADA_DEFAULT_READ_AHEAD;
static int ada_write_cache = ADA_DEFAULT_WRITE_CACHE;
-static int64_t ada_default_max_delete = ADA_DEFAULT_MAX_DELETE;
static SYSCTL_NODE(_kern_cam, OID_AUTO, ada, CTLFLAG_RD, 0,
"CAM Direct Access Disk driver");
@@ -900,9 +895,6 @@ SYSCTL_INT(_kern_cam_ada, OID_AUTO, read_ahead, CTLFLA
_read_ahead, 0, "Enable disk read-ahead");
SYSCTL_INT(_kern_cam_ada, OID_AUTO, write_cache, CTLFLAG_RWTUN,
_write_cache, 0, "Enable disk write cache");
-SYSCTL_QUAD(_kern_cam_ada, OID_AUTO, default_max_delete, CTLFLAG_RWTUN,
-_default_max_delete, 0,
-"Default system wide maximum delete");
/*
* ADA_ORDEREDTAG_INTERVAL determines how often, relative
@@ -3400,8 +3392,6 @@ adasetgeom(struct ada_softc *softc, struct ccb_getdev
softc->disk->d_delmaxsize = 256 * softc->params.secsize;
} else
softc->disk->d_delmaxsize = maxio;
- if (softc->disk->d_delmaxsize > ada_default_max_delete)
- softc->disk->d_delmaxsize = ada_default_max_delete;
if ((softc->cpi.hba_misc & PIM_UNMAPPED) != 0) {
d_flags |= DISKFLAG_UNMAPPED_BIO;
softc->unmappedio = 1;
Modified: head/sys/cam/scsi/scsi_da.c
==
--- head/sys/cam/scsi/scsi_da.c Mon Dec 16 19:08:49 2019(r355816)
+++ head/sys/cam/scsi/scsi_da.c Mon Dec 16 19:16:26 2019(r355817)
@@ -1516,17 +1516,12 @@ static callout_func_t damediapoll;
#defineDA_DEFAULT_SEND_ORDERED 1
#endif
-#ifndefDA_DEFAULT_MAX_DELETE
-#defineDA_DEFAULT_MAX_DELETE (1 * 1024 * 1024 * 1024)/* 1GB
max trim by default */
-#endif
-
static int da_poll_period = DA_DEFAULT_POLL_PERIOD;
static int da_retry_count = DA_DEFAULT_RETRY;
static int da_default_timeout = DA_DEFAULT_TIMEOUT;
static sbintime_t da_default_softtimeout = DA_DEFAULT_SOFTTIMEOUT;
static int da_send_ordered = DA_DEFAULT_SEND_ORDERED;
static int da_disable_wp_detection = 0;
-static int64_t da_default_max_delete = DA_DEFAULT_MAX_DELETE;
static SYSCTL_NODE(_kern_cam, OID_AUTO, da, CTLFLAG_RD, 0,
"CAM Direct Access Disk driver");
@@ -1541,9 +1536,6 @@ SYSCTL_INT(_kern_cam_da, OID_AUTO, send_ordered, CTLFL
SYSCTL_INT(_kern_cam_da, OID_AUTO, disable_wp_detection, CTLFLAG_RWTUN,
_disable_wp_detection, 0,
"Disable detection of write-protected disks");
-SYSCTL_INT64(_kern_cam_da, OID_AUTO, default_max_delete, CTLFLAG_RWTUN,
-_default_max_delete, 0,
-"Default system wide maximum delete");
SYSCTL_PROC(_kern_cam_da, OID_AUTO, default_softtimeout,
CTLTYPE_UINT | CTLFLAG_RW, NULL, 0, dasysctlsofttimeout, "I",
@@ -2508,8 +2500,8 @@ dadeletemaxsize(struct da_softc *softc, da_delete_meth
return 0;
}
- return (off_t)MIN(da_default_max_delete, softc->params.secsize *
- omin(sectors, softc->params.sectors));
+ return (off_t)softc->params.secsize *
+ omin(sectors, softc->params.sectors);
}
static void
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355816 - head
Author: emaste Date: Mon Dec 16 19:08:49 2019 New Revision: 355816 URL: https://svnweb.freebsd.org/changeset/base/355816 Log: UPDATING: remove outdated caution against make -j Reviewed by: imp Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D22836 Modified: head/UPDATING Modified: head/UPDATING == --- head/UPDATING Mon Dec 16 18:43:57 2019(r355815) +++ head/UPDATING Mon Dec 16 19:08:49 2019(r355816) @@ -1934,19 +1934,14 @@ COMMON ITEMS: General Notes - - Avoid using make -j when upgrading. While generally safe, there are - sometimes problems using -j to upgrade. If your upgrade fails with - -j, please try again without -j. From time to time in the past there - have been problems using -j with buildworld and/or installworld. This - is especially true when upgrading between "distant" versions (eg one - that cross a major release boundary or several minor releases, or when - several months have passed on the -current branch). - Sometimes, obscure build problems are the result of environment poisoning. This can happen because the make utility reads its environment when searching for values for global variables. To run your build attempts in an "environmental clean room", prefix all make commands with 'env -i '. See the env(1) manual page for more details. + Occasionally a build failure will occur with "make -j" due to a race + condition. If this happens try building again without -j, and please + report a bug if it happens consistently. When upgrading from one major version to another it is generally best to upgrade to the latest code in the currently installed branch first, then ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355737 - head/share/man/man9
On Sun, Dec 15, 2019, 11:51 AM Rodney W. Grimes wrote: > > Author: imp > > Date: Fri Dec 13 22:32:05 2019 > > New Revision: 355737 > > URL: https://svnweb.freebsd.org/changeset/base/355737 > > > > Log: > > Better copyright advice > > > > Document the common practices around copyrights with "all rights > reserved" in > > them as new copyright notices get added. > > > > It's an open question qhether to point people at the fact that since > the Berne > > convention was ratified, All rights reserved is largely obsolete. > > https://en.wikipedia.org/wiki/All_rights_reserved#Obsolescence has the > > details. The committer's guide will be revised shortly, and it's > likely that's a > > better place for this discussion. If not, I'll add a blurb here. > > > > Reviewed by: jhb@, brooks@ > > Differential Review: https://reviews.freebsd.org/D22800 > > I object to the a review that specifically invites people to it, > is authored and committed in anything short of 24 hours and more > reasonable to actually ALLOW people time to repond of 72 hours. > The project has no fixed policies around reviews and giving time. Several people did look at it and approve it before I committed it. Having said that, this isn't like you've lost your ability to say something forever now that this is in the tree. If you have suggestions to improvement, I'm all ears. I like your notion around (c) being noise, but I'll address that in the review. Warner Regards, > Rod > > > Better copyright advice > AcceptedPublic > Authored by imp on Fri, Dec 13, 12:33. > > > Modified: > > head/share/man/man9/style.9 > > > > Modified: head/share/man/man9/style.9 > > > == > > --- head/share/man/man9/style.9 Fri Dec 13 22:04:13 2019 > (r355736) > > +++ head/share/man/man9/style.9 Fri Dec 13 22:32:05 2019 > (r355737) > > @@ -1,6 +1,5 @@ > > .\"- > > -.\" Copyright (c) 1995-2005 The FreeBSD Project > > -.\" All rights reserved. > > +.\" Copyright (c) 1995-2019 The FreeBSD Project > > .\" > > .\" Redistribution and use in source and binary forms, with or without > > .\" modification, are permitted provided that the following conditions > > @@ -26,7 +25,7 @@ > > .\" From: @(#)style 1.14 (Berkeley) 4/28/95 > > .\" $FreeBSD$ > > .\" > > -.Dd June 3, 2019 > > +.Dd December 13, 2019 > > .Dt STYLE 9 > > .Os > > .Sh NAME > > @@ -84,8 +83,32 @@ comments. > > Comments starting in columns other than the first are never > > considered license statements. > > Use the appropriate SPDX-License-Identifier line before the copyright. > > +If the copyright assertion contains the phrase > > +.Dq Li "All Rights Reserved" > > +that should be on the same line as the word > > +.Dq Li "Copyright" . > > +You should not insert a new copyright line between an old > > +copyright line and this phrase. > > +Instead, you should insert a new copyright phrase after > > +a pre-existing > > +.Dq Li "All Rights Reserved" > > +line. > > +When making changes, it is acceptable to fold an > > +.Dq Li "All Rights Reserved" > > +line with each of the > > +.Dq Li "Copyright" > > +lines. > > +For files that have the > > +.Dq Li "All Rights Reserved" > > +line on the same line(s) as the word > > +.Dq Li "Copyright" , > > +new copyright assertions should be added last. > > +New > > +.Dq Li "Copyright" > > +lines should only be added when making substantial changes to the file, > > +not for trivial changes. > > .Pp > > -After any copyright header, there is a blank line, and the > > +After any copyright and license comment, there is a blank line, and the > > .Li $\$ > > for non C/C++ language source files. > > Version control system ID tags should only exist once in a file > > > > -- > Rod Grimes > rgri...@freebsd.org > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355813 - in head/sys/cam: ata scsi
Author: imp
Date: Mon Dec 16 18:16:44 2019
New Revision: 355813
URL: https://svnweb.freebsd.org/changeset/base/355813
Log:
Implement a system-wide limit or da and ada devices for delete.
Excesively large TRIMs can result in timeouts, which cause big
problems. Limit trims to 1GB to mititgate these issues.
Reviewed by: scottl
Differential Revision: https://reviews.freebsd.org/D22809
Modified:
head/sys/cam/ata/ata_da.c
head/sys/cam/scsi/scsi_da.c
Modified: head/sys/cam/ata/ata_da.c
==
--- head/sys/cam/ata/ata_da.c Mon Dec 16 18:05:28 2019(r355812)
+++ head/sys/cam/ata/ata_da.c Mon Dec 16 18:16:44 2019(r355813)
@@ -858,6 +858,10 @@ static voidadaresume(void *arg);
#defineADA_DEFAULT_WRITE_CACHE 1
#endif
+#ifndefADA_DEFAULT_MAX_DELETE
+#defineADA_DEFAULT_MAX_DELETE (1 * 1024 * 1024 * 1024)/* 1GB
max trim by default */
+#endif
+
#defineADA_RA (softc->read_ahead >= 0 ? \
softc->read_ahead : ada_read_ahead)
#defineADA_WC (softc->write_cache >= 0 ? \
@@ -878,6 +882,7 @@ static int ada_spindown_shutdown = ADA_DEFAULT_SPINDOW
static int ada_spindown_suspend = ADA_DEFAULT_SPINDOWN_SUSPEND;
static int ada_read_ahead = ADA_DEFAULT_READ_AHEAD;
static int ada_write_cache = ADA_DEFAULT_WRITE_CACHE;
+static int64_t ada_default_max_delete = ADA_DEFAULT_MAX_DELETE;
static SYSCTL_NODE(_kern_cam, OID_AUTO, ada, CTLFLAG_RD, 0,
"CAM Direct Access Disk driver");
@@ -895,6 +900,9 @@ SYSCTL_INT(_kern_cam_ada, OID_AUTO, read_ahead, CTLFLA
_read_ahead, 0, "Enable disk read-ahead");
SYSCTL_INT(_kern_cam_ada, OID_AUTO, write_cache, CTLFLAG_RWTUN,
_write_cache, 0, "Enable disk write cache");
+SYSCTL_QUAD(_kern_cam_ada, OID_AUTO, default_max_delete, CTLFLAG_RWTUN,
+_default_max_delete, 0,
+"Default system wide maximum delete");
/*
* ADA_ORDEREDTAG_INTERVAL determines how often, relative
@@ -3392,6 +3400,8 @@ adasetgeom(struct ada_softc *softc, struct ccb_getdev
softc->disk->d_delmaxsize = 256 * softc->params.secsize;
} else
softc->disk->d_delmaxsize = maxio;
+ if (softc->disk->d_delmaxsize > ada_default_max_delete)
+ softc->disk->d_delmaxsize = ada_default_max_delete;
if ((softc->cpi.hba_misc & PIM_UNMAPPED) != 0) {
d_flags |= DISKFLAG_UNMAPPED_BIO;
softc->unmappedio = 1;
Modified: head/sys/cam/scsi/scsi_da.c
==
--- head/sys/cam/scsi/scsi_da.c Mon Dec 16 18:05:28 2019(r355812)
+++ head/sys/cam/scsi/scsi_da.c Mon Dec 16 18:16:44 2019(r355813)
@@ -1516,12 +1516,17 @@ static callout_func_t damediapoll;
#defineDA_DEFAULT_SEND_ORDERED 1
#endif
+#ifndefDA_DEFAULT_MAX_DELETE
+#defineDA_DEFAULT_MAX_DELETE (1 * 1024 * 1024 * 1024)/* 1GB
max trim by default */
+#endif
+
static int da_poll_period = DA_DEFAULT_POLL_PERIOD;
static int da_retry_count = DA_DEFAULT_RETRY;
static int da_default_timeout = DA_DEFAULT_TIMEOUT;
static sbintime_t da_default_softtimeout = DA_DEFAULT_SOFTTIMEOUT;
static int da_send_ordered = DA_DEFAULT_SEND_ORDERED;
static int da_disable_wp_detection = 0;
+static int64_t da_default_max_delete = DA_DEFAULT_MAX_DELETE;
static SYSCTL_NODE(_kern_cam, OID_AUTO, da, CTLFLAG_RD, 0,
"CAM Direct Access Disk driver");
@@ -1536,6 +1541,9 @@ SYSCTL_INT(_kern_cam_da, OID_AUTO, send_ordered, CTLFL
SYSCTL_INT(_kern_cam_da, OID_AUTO, disable_wp_detection, CTLFLAG_RWTUN,
_disable_wp_detection, 0,
"Disable detection of write-protected disks");
+SYSCTL_INT64(_kern_cam_da, OID_AUTO, default_max_delete, CTLFLAG_RWTUN,
+_default_max_delete, 0,
+"Default system wide maximum delete");
SYSCTL_PROC(_kern_cam_da, OID_AUTO, default_softtimeout,
CTLTYPE_UINT | CTLFLAG_RW, NULL, 0, dasysctlsofttimeout, "I",
@@ -2500,8 +2508,8 @@ dadeletemaxsize(struct da_softc *softc, da_delete_meth
return 0;
}
- return (off_t)softc->params.secsize *
- omin(sectors, softc->params.sectors);
+ return (off_t)MIN(da_default_max_delete, softc->params.secsize *
+ omin(sectors, softc->params.sectors));
}
static void
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355784 - in head/sys: compat/linuxkpi/common/src dev/dpaa kern mips/nlm sys
On Mon, 16 Dec 2019, Ryan Libby wrote: On Mon, Dec 16, 2019 at 7:30 AM Ed Maste wrote: On Sun, 15 Dec 2019 at 16:27, Jeff Roberson wrote: Author: jeff Date: Sun Dec 15 21:26:50 2019 New Revision: 355784 URL: https://svnweb.freebsd.org/changeset/base/355784 Log: schedlock 4/4 FYI i386, arm, arm64, riscv fail to boot now, with "panic: invalid count 2" Boot logs: i386: https://ci.freebsd.org/job/FreeBSD-head-i386-test/7797/console arm: https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-beaglebone-test/1317/artifact/device_tests/beaglebone.boot.log arm64: https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-pinea64-test/1194/artifact/device_tests/pinea64.boot.log riscv: https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-pinea64-test/1194/artifact/device_tests/pinea64.boot.log arm64 is: panic: invalid count 2 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0x007359ec lr = 0x00106744 sp = 0x56b063c0 fp = 0x56b065d0 db_trace_self_wrapper() at vpanic+0x18c pc = 0x00106744 lr = 0x00408128 sp = 0x56b065e0 fp = 0x56b06690 vpanic() at panic+0x44 pc = 0x00408128 lr = 0x00407ed8 sp = 0x56b066a0 fp = 0x56b06720 panic() at sched_switch+0x81c pc = 0x00407ed8 lr = 0x00434264 sp = 0x56b06730 fp = 0x56b06810 sched_switch() at mi_switch+0x170 pc = 0x00434264 lr = 0x00413690 sp = 0x56b06820 fp = 0x56b06840 mi_switch() at cpu_idle+0xc8 pc = 0x00413690 lr = 0x007400a0 sp = 0x56b06850 fp = 0x56b06860 cpu_idle() at sched_idletd+0x380 pc = 0x007400a0 lr = 0x00436a90 sp = 0x56b06870 fp = 0x56b06940 sched_idletd() at fork_exit+0x7c pc = 0x00436a90 lr = 0x003c7ba4 sp = 0x56b06950 fp = 0x56b06980 fork_exit() at fork_trampoline+0x10 pc = 0x003c7ba4 lr = 0x007521ac sp = 0x56b06990 fp = 0x KDB: enter: panic [ thread pid 11 tid 13 ] Stopped at 0 db> It looks like amd64 vs i386, riscv, etc are using different motifs in spinlock_exit(). Perhaps we just need to rearrange them to drop the spinlock count before critical_exit(), like in amd64. It took me a moment to see why but I believe you are right. Interrupts being disabled would prevent a local preemption with the flags out of sync but critical_exit() might have owepreempt set so we will switch before updating the count. Jeff Ryan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355807 - head/sys/compat/linux
Author: trasz
Date: Mon Dec 16 17:45:15 2019
New Revision: 355807
URL: https://svnweb.freebsd.org/changeset/base/355807
Log:
Don't use K definitions. No functional changes.
Reported by: kib
MFC after:2 weeks
Sponsored by: The FreeBSD Foundation
Modified:
head/sys/compat/linux/linux_file.c
Modified: head/sys/compat/linux/linux_file.c
==
--- head/sys/compat/linux/linux_file.c Mon Dec 16 16:41:24 2019
(r355806)
+++ head/sys/compat/linux/linux_file.c Mon Dec 16 17:45:15 2019
(r355807)
@@ -899,18 +899,14 @@ linux_linkat(struct thread *td, struct linux_linkat_ar
}
int
-linux_fdatasync(td, uap)
- struct thread *td;
- struct linux_fdatasync_args *uap;
+linux_fdatasync(struct thread *td, struct linux_fdatasync_args *uap)
{
return (kern_fsync(td, uap->fd, false));
}
int
-linux_sync_file_range(td, uap)
- struct thread *td;
- struct linux_sync_file_range_args *uap;
+linux_sync_file_range(struct thread *td, struct linux_sync_file_range_args
*uap)
{
if (uap->offset < 0 || uap->nbytes < 0 ||
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355784 - in head/sys: compat/linuxkpi/common/src dev/dpaa kern mips/nlm sys
On Mon, Dec 16, 2019 at 7:30 AM Ed Maste wrote: > > On Sun, 15 Dec 2019 at 16:27, Jeff Roberson wrote: > > > > Author: jeff > > Date: Sun Dec 15 21:26:50 2019 > > New Revision: 355784 > > URL: https://svnweb.freebsd.org/changeset/base/355784 > > > > Log: > > schedlock 4/4 > > FYI i386, arm, arm64, riscv fail to boot now, with "panic: invalid count 2" > > Boot logs: > i386: https://ci.freebsd.org/job/FreeBSD-head-i386-test/7797/console > arm: > https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-beaglebone-test/1317/artifact/device_tests/beaglebone.boot.log > arm64: > https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-pinea64-test/1194/artifact/device_tests/pinea64.boot.log > riscv: > https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-pinea64-test/1194/artifact/device_tests/pinea64.boot.log > > arm64 is: > > panic: invalid count 2 > cpuid = 0 > time = 1 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc = 0x007359ec lr = 0x00106744 > sp = 0x56b063c0 fp = 0x56b065d0 > > db_trace_self_wrapper() at vpanic+0x18c > pc = 0x00106744 lr = 0x00408128 > sp = 0x56b065e0 fp = 0x56b06690 > > vpanic() at panic+0x44 > pc = 0x00408128 lr = 0x00407ed8 > sp = 0x56b066a0 fp = 0x56b06720 > > panic() at sched_switch+0x81c > pc = 0x00407ed8 lr = 0x00434264 > sp = 0x56b06730 fp = 0x56b06810 > > sched_switch() at mi_switch+0x170 > pc = 0x00434264 lr = 0x00413690 > sp = 0x56b06820 fp = 0x56b06840 > > mi_switch() at cpu_idle+0xc8 > pc = 0x00413690 lr = 0x007400a0 > sp = 0x56b06850 fp = 0x56b06860 > > cpu_idle() at sched_idletd+0x380 > pc = 0x007400a0 lr = 0x00436a90 > sp = 0x56b06870 fp = 0x56b06940 > > sched_idletd() at fork_exit+0x7c > pc = 0x00436a90 lr = 0x003c7ba4 > sp = 0x56b06950 fp = 0x56b06980 > > fork_exit() at fork_trampoline+0x10 > pc = 0x003c7ba4 lr = 0x007521ac > sp = 0x56b06990 fp = 0x > > KDB: enter: panic > [ thread pid 11 tid 13 ] > Stopped at 0 > db> It looks like amd64 vs i386, riscv, etc are using different motifs in spinlock_exit(). Perhaps we just need to rearrange them to drop the spinlock count before critical_exit(), like in amd64. Ryan ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355806 - in head/sys/dev: adb gpio hyperv/input kbdmux usb/input vkbd
Author: kevans
Date: Mon Dec 16 16:41:24 2019
New Revision: 355806
URL: https://svnweb.freebsd.org/changeset/base/355806
Log:
kbd drivers: don't double register keyboard drivers
Keyboard drivers are generally registered via linker set. In these cases,
they're also available as kmods which use KPI for registering/unregistering
keyboard drivers outside of the linker set.
For built-in modules, we still fire off MOD_LOAD and maybe even MOD_UNLOAD
if an error occurs, leading to registration via linker set and at MOD_LOAD
time.
This is a minor optimization at best, but it keeps the internal kbd driver
tidy as a future change will merge the linker set driver list into its
internal keyboard_drivers list via SYSINIT and simplify driver lookup by
removing the need to consult the linker set.
Modified:
head/sys/dev/adb/adb_kbd.c
head/sys/dev/gpio/gpiokeys.c
head/sys/dev/hyperv/input/hv_kbd.c
head/sys/dev/kbdmux/kbdmux.c
head/sys/dev/usb/input/ukbd.c
head/sys/dev/vkbd/vkbd.c
Modified: head/sys/dev/adb/adb_kbd.c
==
--- head/sys/dev/adb/adb_kbd.c Mon Dec 16 15:41:32 2019(r355805)
+++ head/sys/dev/adb/adb_kbd.c Mon Dec 16 16:41:24 2019(r355806)
@@ -850,11 +850,15 @@ akbd_modevent(module_t mod, int type, void *data)
{
switch (type) {
case MOD_LOAD:
+#ifdef KLD_MODULE
kbd_add_driver(_kbd_driver);
+#endif
break;
case MOD_UNLOAD:
+#ifdef KLD_MODULE
kbd_delete_driver(_kbd_driver);
+#endif
break;
default:
Modified: head/sys/dev/gpio/gpiokeys.c
==
--- head/sys/dev/gpio/gpiokeys.cMon Dec 16 15:41:32 2019
(r355805)
+++ head/sys/dev/gpio/gpiokeys.cMon Dec 16 16:41:24 2019
(r355806)
@@ -983,6 +983,8 @@ KEYBOARD_DRIVER(gpiokeys, gpiokeyssw, gpiokeys_configu
static int
gpiokeys_driver_load(module_t mod, int what, void *arg)
{
+
+#ifdef KLD_MODULE
switch (what) {
case MOD_LOAD:
kbd_add_driver(_kbd_driver);
@@ -991,6 +993,7 @@ gpiokeys_driver_load(module_t mod, int what, void *arg
kbd_delete_driver(_kbd_driver);
break;
}
+#endif
return (0);
}
Modified: head/sys/dev/hyperv/input/hv_kbd.c
==
--- head/sys/dev/hyperv/input/hv_kbd.c Mon Dec 16 15:41:32 2019
(r355805)
+++ head/sys/dev/hyperv/input/hv_kbd.c Mon Dec 16 16:41:24 2019
(r355806)
@@ -490,6 +490,8 @@ hv_kbd_intr(hv_kbd_sc *sc)
int
hvkbd_driver_load(module_t mod, int what, void *arg)
{
+
+#ifdef KLD_MODULE
switch (what) {
case MOD_LOAD:
kbd_add_driver(_kbd_driver);
@@ -498,6 +500,7 @@ hvkbd_driver_load(module_t mod, int what, void *arg)
kbd_delete_driver(_kbd_driver);
break;
}
+#endif
return (0);
}
Modified: head/sys/dev/kbdmux/kbdmux.c
==
--- head/sys/dev/kbdmux/kbdmux.cMon Dec 16 15:41:32 2019
(r355805)
+++ head/sys/dev/kbdmux/kbdmux.cMon Dec 16 16:41:24 2019
(r355806)
@@ -1423,11 +1423,15 @@ kbdmux_modevent(module_t mod, int type, void *data)
switch (type) {
case MOD_LOAD:
+#ifdef KLD_MODULE
if ((error = kbd_add_driver(_kbd_driver)) != 0)
break;
+#endif
if ((sw = kbd_get_switch(KEYBOARD_NAME)) == NULL) {
+#ifdef KLD_MODULE
kbd_delete_driver(_kbd_driver);
+#endif
error = ENXIO;
break;
}
@@ -1436,14 +1440,18 @@ kbdmux_modevent(module_t mod, int type, void *data)
if ((error = (*sw->probe)(0, NULL, 0)) != 0 ||
(error = (*sw->init)(0, , NULL, 0)) != 0) {
+#ifdef KLD_MODULE
kbd_delete_driver(_kbd_driver);
+#endif
break;
}
#ifdef KBD_INSTALL_CDEV
if ((error = kbd_attach(kbd)) != 0) {
(*sw->term)(kbd);
+#ifdef KLD_MODULE
kbd_delete_driver(_kbd_driver);
+#endif
break;
}
#endif
@@ -1454,7 +1462,9 @@ kbdmux_modevent(module_t mod, int type, void *data)
kbd_detach(kbd);
#endif
(*sw->term)(kbd);
+#ifdef KLD_MODULE
kbd_delete_driver(_kbd_driver);
+#endif
break;
}
break;
@@ -1470,7 +1480,9 @@ kbdmux_modevent(module_t mod, int type, void *data)
kbd_detach(kbd);
#endif
(*sw->term)(kbd);
+#ifdef KLD_MODULE
Re: svn commit: r355784 - in head/sys: compat/linuxkpi/common/src dev/dpaa kern mips/nlm sys
On Sun, 15 Dec 2019 at 16:27, Jeff Roberson wrote: > > Author: jeff > Date: Sun Dec 15 21:26:50 2019 > New Revision: 355784 > URL: https://svnweb.freebsd.org/changeset/base/355784 > > Log: > schedlock 4/4 FYI i386, arm, arm64, riscv fail to boot now, with "panic: invalid count 2" Boot logs: i386: https://ci.freebsd.org/job/FreeBSD-head-i386-test/7797/console arm: https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-beaglebone-test/1317/artifact/device_tests/beaglebone.boot.log arm64: https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-pinea64-test/1194/artifact/device_tests/pinea64.boot.log riscv: https://ci.freebsd.org/hwlab/job/FreeBSD-device-head-pinea64-test/1194/artifact/device_tests/pinea64.boot.log arm64 is: panic: invalid count 2 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0x007359ec lr = 0x00106744 sp = 0x56b063c0 fp = 0x56b065d0 db_trace_self_wrapper() at vpanic+0x18c pc = 0x00106744 lr = 0x00408128 sp = 0x56b065e0 fp = 0x56b06690 vpanic() at panic+0x44 pc = 0x00408128 lr = 0x00407ed8 sp = 0x56b066a0 fp = 0x56b06720 panic() at sched_switch+0x81c pc = 0x00407ed8 lr = 0x00434264 sp = 0x56b06730 fp = 0x56b06810 sched_switch() at mi_switch+0x170 pc = 0x00434264 lr = 0x00413690 sp = 0x56b06820 fp = 0x56b06840 mi_switch() at cpu_idle+0xc8 pc = 0x00413690 lr = 0x007400a0 sp = 0x56b06850 fp = 0x56b06860 cpu_idle() at sched_idletd+0x380 pc = 0x007400a0 lr = 0x00436a90 sp = 0x56b06870 fp = 0x56b06940 sched_idletd() at fork_exit+0x7c pc = 0x00436a90 lr = 0x003c7ba4 sp = 0x56b06950 fp = 0x56b06980 fork_exit() at fork_trampoline+0x10 pc = 0x003c7ba4 lr = 0x007521ac sp = 0x56b06990 fp = 0x KDB: enter: panic [ thread pid 11 tid 13 ] Stopped at 0 db> ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355803 - in head: contrib/libunwind/src lib/libgcc_s lib/libgcc_s/arm
Author: mmel
Date: Mon Dec 16 14:08:49 2019
New Revision: 355803
URL: https://svnweb.freebsd.org/changeset/base/355803
Log:
Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM.
In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version
for all architectures but ARM. For ARM should be publishes with GCC_4.3.0
version. This was originally omitted in r255095, fixed in r318024 and omitted
aging in LLVM libunwind implementation in r354347.
For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0
version , (because this is right original version) and again as
normal(not-default) with GCC_3.3 version (to maintain ABI compatibility
compiled/linked with wrong pre r318024 libgcc)
PR: 233664
Added:
head/lib/libgcc_s/SymbolDefault.map (contents, props changed)
Modified:
head/contrib/libunwind/src/UnwindLevel1-gcc-ext.c
head/lib/libgcc_s/Makefile
head/lib/libgcc_s/Symbol.map
head/lib/libgcc_s/arm/Symbol.map
Modified: head/contrib/libunwind/src/UnwindLevel1-gcc-ext.c
==
--- head/contrib/libunwind/src/UnwindLevel1-gcc-ext.c Mon Dec 16 13:32:06
2019(r355802)
+++ head/contrib/libunwind/src/UnwindLevel1-gcc-ext.c Mon Dec 16 14:08:49
2019(r355803)
@@ -182,8 +182,8 @@ _Unwind_Backtrace(_Unwind_Trace_Fn callback, void *ref
}
}
#ifdef __arm__
-/* Preserve legacy libgcc ARM ABI mistake. */
-__sym_compat(_Unwind_Backtrace, _Unwind_Backtrace, GCC_4.3.0);
+/* Preserve legacy libgcc (pre r318024) ARM ABI mistake */
+__sym_compat(_Unwind_Backtrace, _Unwind_Backtrace, GCC_3.3);
#endif
Modified: head/lib/libgcc_s/Makefile
==
--- head/lib/libgcc_s/Makefile Mon Dec 16 13:32:06 2019(r355802)
+++ head/lib/libgcc_s/Makefile Mon Dec 16 14:08:49 2019(r355803)
@@ -18,6 +18,8 @@ SYMBOL_MAPS= ${.CURDIR}/Symbol.map
# Export ARM AEABI unwind routines needed by libc and libthr.
.if exists(${.CURDIR}/${MACHINE_CPUARCH}/Symbol.map)
SYMBOL_MAPS+= ${.CURDIR}/${MACHINE_CPUARCH}/Symbol.map
+.else
+SYMBOL_MAPS+= ${.CURDIR}/SymbolDefault.map
.endif
.endif
Modified: head/lib/libgcc_s/Symbol.map
==
--- head/lib/libgcc_s/Symbol.mapMon Dec 16 13:32:06 2019
(r355802)
+++ head/lib/libgcc_s/Symbol.mapMon Dec 16 14:08:49 2019
(r355803)
@@ -86,7 +86,6 @@ GCC_3.0 {
};
GCC_3.3 {
- _Unwind_Backtrace;
_Unwind_FindEnclosingFunction;
_Unwind_GetCFA;
_Unwind_Resume_or_Rethrow;
Added: head/lib/libgcc_s/SymbolDefault.map
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libgcc_s/SymbolDefault.map Mon Dec 16 14:08:49 2019
(r355803)
@@ -0,0 +1,7 @@
+/*
+ * $FreeBSD$
+ */
+/* _Unwind_Backtrace should be exported with different version on ARM */
+GCC_3.3 {
+ _Unwind_Backtrace;
+};
Modified: head/lib/libgcc_s/arm/Symbol.map
==
--- head/lib/libgcc_s/arm/Symbol.mapMon Dec 16 13:32:06 2019
(r355802)
+++ head/lib/libgcc_s/arm/Symbol.mapMon Dec 16 14:08:49 2019
(r355803)
@@ -10,3 +10,7 @@ GCC_3.5 {
__aeabi_unwind_cpp_pr2;
__gnu_unwind_frame;
};
+
+GCC_4.3.0 {
+ _Unwind_Backtrace;
+};
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355802 - head/sys/sys
Author: lwhsu Date: Mon Dec 16 13:32:06 2019 New Revision: 355802 URL: https://svnweb.freebsd.org/changeset/base/355802 Log: Fix gcc build after r355790 Sponsored by: The FreeBSD Foundation Modified: head/sys/sys/vnode.h Modified: head/sys/sys/vnode.h == --- head/sys/sys/vnode.hMon Dec 16 13:17:39 2019(r355801) +++ head/sys/sys/vnode.hMon Dec 16 13:32:06 2019(r355802) @@ -961,8 +961,6 @@ void vn_fsid(struct vnode *vp, struct vattr *va); SYSINIT(vfs_vector_##vnodeops##_f, SI_SUB_VFS, SI_ORDER_ANY, \ vfs_vector_op_register, ) -void vfs_vector_op_register(struct vop_vector *vop); - #endif /* _KERNEL */ #endif /* !_SYS_VNODE_H_ */ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355801 - in head/sys: gdb powerpc/include powerpc/powerpc
Author: luporl
Date: Mon Dec 16 13:17:39 2019
New Revision: 355801
URL: https://svnweb.freebsd.org/changeset/base/355801
Log:
[PPC] Handle qOffsets packet
On PowerPC, this is needed in order for the debugger to find out
the memory offset where the kernel image was loaded on the remote
target.
This fixes symbol resolution when remote debugging a PowerPC kernel.
Reviewed by: cem
Differential Revision:https://reviews.freebsd.org/D22767
Modified:
head/sys/gdb/gdb_main.c
head/sys/powerpc/include/gdb_machdep.h
head/sys/powerpc/powerpc/gdb_machdep.c
Modified: head/sys/gdb/gdb_main.c
==
--- head/sys/gdb/gdb_main.c Mon Dec 16 09:11:38 2019(r355800)
+++ head/sys/gdb/gdb_main.c Mon Dec 16 13:17:39 2019(r355801)
@@ -769,6 +769,10 @@ gdb_trap(int type, int code)
do_qXfer();
} else if (gdb_rx_equal("Search:memory:")) {
gdb_do_mem_search();
+#ifdef __powerpc__
+ } else if (gdb_rx_equal("Offsets")) {
+ gdb_cpu_do_offsets();
+#endif
} else if (!gdb_cpu_query())
gdb_tx_empty();
break;
Modified: head/sys/powerpc/include/gdb_machdep.h
==
--- head/sys/powerpc/include/gdb_machdep.h Mon Dec 16 09:11:38 2019
(r355800)
+++ head/sys/powerpc/include/gdb_machdep.h Mon Dec 16 13:17:39 2019
(r355801)
@@ -131,5 +131,6 @@ gdb_end_write(void *arg __unused)
void *gdb_cpu_getreg(int, size_t *);
void gdb_cpu_setreg(int, void *);
int gdb_cpu_signal(int, int);
+void gdb_cpu_do_offsets(void);
#endif /* !_MACHINE_GDB_MACHDEP_H_ */
Modified: head/sys/powerpc/powerpc/gdb_machdep.c
==
--- head/sys/powerpc/powerpc/gdb_machdep.c Mon Dec 16 09:11:38 2019
(r355800)
+++ head/sys/powerpc/powerpc/gdb_machdep.c Mon Dec 16 13:17:39 2019
(r355801)
@@ -48,6 +48,8 @@ __FBSDID("$FreeBSD$");
#include
#include
+extern vm_offset_t __startkernel;
+
void *
gdb_cpu_getreg(int regnum, size_t *regsz)
{
@@ -100,4 +102,29 @@ gdb_cpu_signal(int vector, int dummy __unused)
return (vector);
else
return (SIGEMT);
+}
+
+void
+gdb_cpu_do_offsets(void)
+{
+ /*
+* On PowerPC, .text starts at KERNBASE + SIZEOF_HEADERS and
+* text segment at KERNBASE - SIZEOF_HEADERS.
+* On PowerPC64, .text starts at KERNBASE and text segment at
+* KERNBASE - 0x100.
+* In both cases, the text segment offset is aligned to 64KB.
+*
+* The __startkernel variable holds the relocated KERNBASE offset.
+* Thus, as long as SIZEOF_HEADERS doesn't get bigger than 0x100
+* (which would lead to other issues), aligning __startkernel to
+* 64KB gives the text segment offset.
+*
+* TODO: Add DataSeg to response. On PowerPC64 all sections reside
+* in a single LOAD segment, but on PowerPC modifiable data reside
+* in a separate segment, that GDB should also relocate.
+*/
+ gdb_tx_begin(0);
+ gdb_tx_str("TextSeg=");
+ gdb_tx_varhex(__startkernel & ~0x);
+ gdb_tx_end();
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r355800 - head/lib/libpcap
Author: hselasky
Date: Mon Dec 16 09:11:38 2019
New Revision: 355800
URL: https://svnweb.freebsd.org/changeset/base/355800
Log:
Install missing pcap(3) manual pages and add missing manpage
section substitutions.
Submitted by: Martin Beran
PR: 237893
MFC after:1 week
Sponsored by: Mellanox Technologies
Modified:
head/lib/libpcap/Makefile
Modified: head/lib/libpcap/Makefile
==
--- head/lib/libpcap/Makefile Mon Dec 16 04:52:06 2019(r355799)
+++ head/lib/libpcap/Makefile Mon Dec 16 09:11:38 2019(r355800)
@@ -109,7 +109,11 @@ MAN= pcap.3 \
pcap_statustostr.3 \
pcap_strerror.3 \
pcap_tstamp_type_name_to_val.3 \
- pcap_tstamp_type_val_to_name.3
+ pcap_tstamp_type_val_to_name.3 \
+ pcap-savefile.5 \
+ pcap-filter.7 \
+ pcap-linktype.7 \
+ pcap-tstamp.7
MLINKS= \
pcap_datalink_val_to_name.3 pcap_datalink_val_to_description.3 \
@@ -173,7 +177,7 @@ tokdefs.h: grammar.h .NOMETA
${_page}:
if [ -f ${PCAP_DISTDIR}/${_page:S/3$/3pcap/} ]; then\
F=${_page:S/3$/3pcap/}; \
- elif [ -f ${PCAP_DISTDIR}/${_page:S/3$/3pcap.in/} ]; then
\
+ elif [ -f ${PCAP_DISTDIR}/${_page:S/3$/3pcap.in/} ]; then \
F=${_page:S/3$/3pcap.in/}; \
elif [ -f ${PCAP_DISTDIR}/${_page:S/5$/manfile.in/} ]; then \
F=${_page:S/5$/manfile.in/};\
@@ -182,7 +186,12 @@ ${_page}:
else\
F=${_page:S/7$/manmisc.in/};\
fi; \
- sed -e 's/3PCAP/3/g' ${PCAP_DISTDIR}/$$F > ${_page}
+ sed \
+ -e 's/3PCAP/3/g' \
+ -e 's/@MAN_FILE_FORMATS@/5/g' \
+ -e 's/@MAN_MISC_INFO@/7/g' \
+ -e 's/@MAN_ADMIN_COMMANDS@/8/g' \
+ ${PCAP_DISTDIR}/$$F > ${_page}
.endfor
.include
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r355611 - head/sys/kern
On 12/12/2019 00:00, Konstantin Belousov wrote:
> On Wed, Dec 11, 2019 at 03:52:30PM +, Andriy Gapon wrote:
>> Author: avg
>> Date: Wed Dec 11 15:52:29 2019
>> New Revision: 355611
>> URL: https://svnweb.freebsd.org/changeset/base/355611
>>
>> Log:
>> add a sanity check to the system call registration code
>>
>> A system call number should be at least reserved.
>> We do not expect an attempt to register a fixed number system call
>> when nothing at all is known about it.
>>
>> MFC after: 3 weeks
>> Sponsored by: Panzura
>>
>> Modified:
>> head/sys/kern/kern_syscalls.c
>>
>> Modified: head/sys/kern/kern_syscalls.c
>> ==
>> --- head/sys/kern/kern_syscalls.cWed Dec 11 15:15:21 2019
>> (r355610)
>> +++ head/sys/kern/kern_syscalls.cWed Dec 11 15:52:29 2019
>> (r355611)
>> @@ -120,11 +120,14 @@ kern_syscall_register(struct sysent *sysents, int *off
>> if (i == SYS_MAXSYSCALL)
>> return (ENFILE);
>> *offset = i;
>> -} else if (*offset < 0 || *offset >= SYS_MAXSYSCALL)
>> +} else if (*offset < 0 || *offset >= SYS_MAXSYSCALL) {
>> return (EINVAL);
>> -else if (sysents[*offset].sy_call != (sy_call_t *)lkmnosys &&
>> -sysents[*offset].sy_call != (sy_call_t *)lkmressys)
>> +} else if (sysents[*offset].sy_call != (sy_call_t *)lkmnosys &&
>> +sysents[*offset].sy_call != (sy_call_t *)lkmressys) {
>> +KASSERT(sysents[*offset].sy_call != NULL,
>> +("undefined syscall %d", *offset));
> I do not think that the assert is very useful. On debug kernels, where
> the development would most likely take place, its only function is to annoy
> developer by requiring him to reboot the host if he did not guessed a
> free syscall number right.
>
> I suggest to convert this into printf, might be also under bootverbose.
>
> Also, why do you say that the syscall is undefined ? I would state that
> it is not reusable for dynamically loaded syscall, instead.
I admit that panic() could be an overreaction to a problem that I somehow
created for myself. And the check is not very robust too (but without false
positives)
.
But we should never see sy_call == NULL in sysents, NULL is not a valid value
for the field.
I think that somehow my init_sysent.c was out-of-sync with the rest of files
generated from syscalls.master. So, I got a situation where I tried to
dynamically register a system that was below SYS_MAXSYSCALL but beyond the end
of sysent[], and apparently that region happened to be zero-filled. So,
confusingly, kern_syscall_register() returned EEXIST.
>> return (EEXIST);
>> +}
>>
>> KASSERT(sysents[*offset].sy_thrcnt == SY_THR_ABSENT,
>> ("dynamic syscall is not protected"));
--
Andriy Gapon
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
