Re: debugging a run of poudriere-bulk
On 3/10/18 9:11 pm, Matthias Apitz wrote: > > Hello, > > > I'm trying to nail down PR 231532 of a port which fails to build in > poudriere. In the last phase of the ports build, while creating the pkg > of the built port with pkg-static, this crashes: > > # tail > /usr/local/poudriere/data/logs/bulk/freebsd-r338641-ports-20180920/2018-10-03_11h32m17s/logs/kde-workspace-kde4-4.11.22_26.log > Child process pid=85086 terminated abnormally: Segmentation fault > *** Error code 1 > > Stop. > make: stopped in /usr/ports/x11/kde-workspace-kde4 > =>> Cleaning up wrkdir > > # grep 85086 /var/log/messages > Oct 3 11:44:01 jet kernel: pid 85086 (pkg-static), uid 65534: exited on > signal 11 > > > How can I enter the jail interactively in the moment after the crash to rerun > and > debug pkg-static? Using poudriere testport -j -p -i -o will drop you into the jail after the build stops, you then rerun make manually, check build logs... Logging out will then continue on and clean up the jail. You can also use -I instead of -i and it leaves the jail in place so you can manually connect to and stop the jail. Note that poudriere uses a clean jail with only deps listed for the port, you can add extra BUILD_DEPENDS to get extra ports (gdb valgrind) installed with the test build. -- FreeBSD - the place to B...Software Developing Shane Ambler ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: which way to update export_args structure?
Brooks Davis wrote:
>On Wed, Oct 03, 2018 at 12:40:27AM +, Rick Macklem wrote:
>> Hi,
>>
>> I am working on updating "struct export_args" to fix/add a few things.
>> One of these is that "ex_flags" is an int, but the flags are defined in
>> mount.h
>> as MNT_xx bits that now exceed 32bits (mnt_flag is now uint64_t).
>> For now, this doesn't break anything, since the flags used by ex_flags are
>> all defined in the low order 32bits but...it seems like this should be
>> addressed
>> by a new version of "struct export_args".
>>
>> I have two versions of the updated structure:
>> A)
>> struct export_args {
>> uint64_t ex_flags; /* export related flags */
>> uid_t ex_root;/* mapping for root uid */
>> struct xucred ex_anon; /* mapping for anonymous user */
>> struct sockaddr *ex_addr; /* net address to which exported */
>> u_char ex_addrlen; /* and the net address length */
>> struct sockaddr *ex_mask; /* mask of valid bits in saddr */
>> u_char ex_masklen; /* and the smask length */
>> char*ex_indexfile; /* index file for WebNFS URLs */
>> int ex_numsecflavors; /* security flavor count */
>> int ex_secflavors[MAXSECFLAVORS]; /* list of security flavors */
>> int32_t ex_fsid;/* mnt_stat.f_fsid.val[0] if */
>> /* MNT_EXPORTFSID set in ex_flags64 */
>> gid_t *ex_suppgroups; /* Supplemental groups if */
>> /* ex_anon.cr_ngroups > XU_NGROUPS */
>> };
>> B)
>> struct export_args {
>> int ex_flags; /* export related flags */
>> uid_t ex_root;/* mapping for root uid */
>> struct xucred ex_anon; /* mapping for anonymous user */
>> struct sockaddr *ex_addr; /* net address to which exported */
>> u_char ex_addrlen; /* and the net address length */
>> struct sockaddr *ex_mask; /* mask of valid bits in saddr */
>> u_char ex_masklen; /* and the smask length */
>> char*ex_indexfile; /* index file for WebNFS URLs */
>> int ex_numsecflavors; /* security flavor count */
>> int ex_secflavors[MAXSECFLAVORS]; /* list of security flavors */
>> uint64_t ex_flagshighbits; /* High order bits of mnt_flag */
>> int32_t ex_fsid;/* mnt_stat.f_fsid.val[0] if */
>> /* MNT_EXPORTFSID set in ex_flags64 */
>> gid_t *ex_suppgroups; /* Supplemental groups if */
>> /* ex_anon.cr_ngroups > XU_NGROUPS */
>> };
>>
>> A) does the obvious thing. Unfortunately, this changes the vfs KABI
>> (specifically the function vfs_oexport_conv()) such that a file system
>> module compiled with an unpatched mount.h could crash a patched system.
>> As such, I think it couldn't be MFC'd and would be stuck in head/current
>> until FreeBSD13 (or FreeBSD14 if 13 gets skipped over;-).
>>
>> B) doesn't change any fields, but adds a second ex_flagshighbits for the high
>> order bit. Since it only adds fields where none of those bits are used after
>> the exports are processed by vfs_export() and, as such, will not break
>> the VFS KABI, since vfs_domount_update() differentiates which version
>> of export_args is being used.
>> As such, I believe this version can be MFC'd. However, it does seem confusing
>> to have the two ex_flags fields for the low and high 32bits.
>
>I see you've found a way to do compatibility for a new ABI. If you
>wanted to avoid changing the struct size, there is 3 bytes of usable
>padding after each ex_addrlen and ex_masklen.
Actually, you want the size to change, since that is how the code detects
a different version of the struct. (Take a look around line# 1037 of
vfs_mount.c).
The additions are a lot more than 6bytes. The reason I was a little hesitant to
change ex_flags to 64bits is that it makes the compatibility code a little
messier,
but it isn't that bad.
The tricky one is vfs_oexport_conv(), because it doesn't know the size of the
struct being passed in via a pointer. My current solution is to have this
function
remain in place for old file system binaries only and add a new function with
a different name (and takes a struct length argument as well as the pointer)
for the new code. This function is only used by three file systems to handle the
old pre-nmount(2) syscall.
>One general question: why does export_args still exist as an interface
>between userspace and the kernel? It's passed via nmount so it seems
>like the individual entries should be elements in the vector instead.
>This would be much friendlier if one wanted to do 32-bit compat support
>for mountd.
Not sure what you are thinking of here. Right now "struct export_args" is the
data
for a mount option
Re: Sound issues with Dell Latitude 7490 (kabylake)
On 10/3/18 7:39 PM, Mario Lobo wrote:
Em qua, 3 de out de 2018 às 14:03, Jakob Alvermark
escreveu:
On 10/3/18 6:19 PM, Mario Lobo wrote:
Em qua, 3 de out de 2018 às 10:10, David Wolfskill
escreveu:
On Mon, Oct 01, 2018 at 11:12:25PM +0200, Jakob Alvermark wrote:
Do the headphones work with this patch?
Index: sys/dev/sound/pci/hda/hdaa.c
===
--- sys/dev/sound/pci/hda/hdaa.c(revision 339076)
+++ sys/dev/sound/pci/hda/hdaa.c(working copy)
@@ -5034,11 +5034,13 @@
pincap = w->wclass.pin.cap;
/* Disable everything. */
+/*
w->wclass.pin.ctrl &= ~(
HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
+*/
if (w->enable == 0) {
/* Pin is unused so left it disabled. */
Thank you! This addressed the long-standing (Reported: 2015-05-29
21:15 UTC) issue I have had with my laptop (Dell Precision M4800), as
documented in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200526
-- now updated to reflect the fix.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Trump is gaslighting us:
https://www.bbc.com/news/world-us-canada-44959300
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Thank you #2 !! The patch fixed my weird headphone sound too on
11.2-STABLE!
I still can't make the plugging-in switch work but it's ok. I created
scripts for that with
Can you send the output from 'sysctl dev.hdaa'?
Jakob
By the way, my note is ACER Aspire 5 A515-51G
Here it is:
[~]>sysctl dev.hdaa
dev.hdaa.1.reconfig: 0
Could you send me the output of 'sysctl dev.pcm' as well?
Thanks,
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: debugging a run of poudriere-bulk
El día miércoles, octubre 03, 2018 a las 11:06:55p. m. +0200, Tobias C. Berner escribió: > Moin moin > > Unfortunately it is very hard to help here when not being able to reproduce > the issue :/ > Have you tried wiping all the packages in poudriere's repo? -- i.e. -c -- > maybe you're pkg package is just hosed. Tobias, The problem *is* reproducible, even in the build clusters of freebsd.org (see pkg-fallout messages). It is only (until now) not debug-able. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October 3: Day of German Unity? No! Day of taking over the GDR. 3. Oktober: Tag der Deutschen Einheit? Nein! DDR-Anschlusstag. signature.asc Description: PGP signature
Re: debugging a run of poudriere-bulk
Moin moin Unfortunately it is very hard to help here when not being able to reproduce the issue :/ Have you tried wiping all the packages in poudriere's repo? -- i.e. -c -- maybe you're pkg package is just hosed. mfg Tobias On Wed, 3 Oct 2018 at 22:30, Matthias Apitz wrote: > > I added the following lines to /usr/local/share/poudriere/bulk.sh to get > the env vars into the environment of pkg(8): > > export DEBUG_LEVEL=4 > export DEBUG_SCRIPTS=TRUE > export DEVELOPER_MODE=TRUE > export PKG_CREATE_VERBOSE=TRUE > > With these the port builds fine: > > # tail -f > /usr/local/poudriere/data/logs/bulk/freebsd-r338641-ports-20180920/2018-10-03_22h03m46s/logs/kde-workspace-kde4-4.11.22_26.log > ... > > DBG(1)[94432]> PkgConfig: loading repositories in /etc/pkg/ > DBG(1)[94432]> PKgConfig: loading /etc/pkg//FreeBSD.conf > DBG(1)[94432]> PkgConfig: parsing key 'FreeBSD' > DBG(1)[94432]> PkgConfig: parsing repository object FreeBSD > DBG(1)[94432]> PkgConfig: loading repositories in /usr/local/etc/pkg/repos/ > DBG(1)[94432]> Creating package from stage directory: > '/wrkdirs/usr/ports/x11/kde-workspace-kde4/wor > k/stage' > DBG(1)[94432]> Parsing manifest from '+MANIFEST' > DBG(3)[94432]> Manifest: found key: 'name' > > ... > > DBG(2)[94432]> Packing file > '/wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/share/wallpapers/stripes.png.desktop' > DBG(2)[94432]> Packing file > '/wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/share/xsessions/kde4.desktop' > DBG(2)[94432]> Packing file > '/wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/etc/rc.d/kdm4' > packing files [2126]... done > packing directories [0]: . done > === > =>> Cleaning up wrkdir > ===> Cleaning for kde-workspace-kde4-4.11.22_26 > build of x11/kde-workspace-kde4 | kde-workspace-kde4-4.11.22_26 ended at > Wed Oct 3 22:15:54 CEST 2018 > build time: 00:11:21 > > i.e. the pkg-static does not crash. > > And now? > > matthias > > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > October 3: Day of German Unity? No! Day of taking over the GDR. > 3. Oktober: Tag der Deutschen Einheit? Nein! DDR-Anschlusstag. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: debugging a run of poudriere-bulk
I added the following lines to /usr/local/share/poudriere/bulk.sh to get the env vars into the environment of pkg(8): export DEBUG_LEVEL=4 export DEBUG_SCRIPTS=TRUE export DEVELOPER_MODE=TRUE export PKG_CREATE_VERBOSE=TRUE With these the port builds fine: # tail -f /usr/local/poudriere/data/logs/bulk/freebsd-r338641-ports-20180920/2018-10-03_22h03m46s/logs/kde-workspace-kde4-4.11.22_26.log ... DBG(1)[94432]> PkgConfig: loading repositories in /etc/pkg/ DBG(1)[94432]> PKgConfig: loading /etc/pkg//FreeBSD.conf DBG(1)[94432]> PkgConfig: parsing key 'FreeBSD' DBG(1)[94432]> PkgConfig: parsing repository object FreeBSD DBG(1)[94432]> PkgConfig: loading repositories in /usr/local/etc/pkg/repos/ DBG(1)[94432]> Creating package from stage directory: '/wrkdirs/usr/ports/x11/kde-workspace-kde4/wor k/stage' DBG(1)[94432]> Parsing manifest from '+MANIFEST' DBG(3)[94432]> Manifest: found key: 'name' ... DBG(2)[94432]> Packing file '/wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/share/wallpapers/stripes.png.desktop' DBG(2)[94432]> Packing file '/wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/share/xsessions/kde4.desktop' DBG(2)[94432]> Packing file '/wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/etc/rc.d/kdm4' packing files [2126]... done packing directories [0]: . done === =>> Cleaning up wrkdir ===> Cleaning for kde-workspace-kde4-4.11.22_26 build of x11/kde-workspace-kde4 | kde-workspace-kde4-4.11.22_26 ended at Wed Oct 3 22:15:54 CEST 2018 build time: 00:11:21 i.e. the pkg-static does not crash. And now? matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October 3: Day of German Unity? No! Day of taking over the GDR. 3. Oktober: Tag der Deutschen Einheit? Nein! DDR-Anschlusstag. signature.asc Description: PGP signature
Re: Sound issues with Dell Latitude 7490 (kabylake)
Em qua, 3 de out de 2018 às 14:03, Jakob Alvermark
escreveu:
> On 10/3/18 6:19 PM, Mario Lobo wrote:
>
> Em qua, 3 de out de 2018 às 10:10, David Wolfskill
> escreveu:
>
>> On Mon, Oct 01, 2018 at 11:12:25PM +0200, Jakob Alvermark wrote:
>> >
>> > Do the headphones work with this patch?
>> >
>> > Index: sys/dev/sound/pci/hda/hdaa.c
>> > ===
>> > --- sys/dev/sound/pci/hda/hdaa.c(revision 339076)
>> > +++ sys/dev/sound/pci/hda/hdaa.c(working copy)
>> > @@ -5034,11 +5034,13 @@
>> > pincap = w->wclass.pin.cap;
>> >
>> > /* Disable everything. */
>> > +/*
>> > w->wclass.pin.ctrl &= ~(
>> > HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
>> > HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
>> > HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
>> > HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
>> > +*/
>> >
>> > if (w->enable == 0) {
>> > /* Pin is unused so left it disabled. */
>> >
>>
>> Thank you! This addressed the long-standing (Reported: 2015-05-29
>> 21:15 UTC) issue I have had with my laptop (Dell Precision M4800), as
>> documented in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200526
>> -- now updated to reflect the fix.
>>
>> Peace,
>> david
>> --
>> David H. Wolfskill da...@catwhisker.org
>> Trump is gaslighting us:
>> https://www.bbc.com/news/world-us-canada-44959300
>>
>> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>>
>
> Thank you #2 !! The patch fixed my weird headphone sound too on
> 11.2-STABLE!
>
> I still can't make the plugging-in switch work but it's ok. I created
> scripts for that with
>
>
> Can you send the output from 'sysctl dev.hdaa'?
>
>
> Jakob
>
By the way, my note is ACER Aspire 5 A515-51G
Here it is:
[~]>sysctl dev.hdaa
dev.hdaa.1.reconfig: 0
dev.hdaa.1.gpo_config:
dev.hdaa.1.gpo_state:
dev.hdaa.1.gpio_config:
dev.hdaa.1.gpio_state:
dev.hdaa.1.gpi_state:
dev.hdaa.1.config: forcestereo,ivref50,ivref80,ivref100,ivref,vref
dev.hdaa.1.nid3_original: 0x18560010 as=1 seq=0 device=Digital-out
conn=Jack ctype=Digital loc=0x18 color=Unknown misc=0
dev.hdaa.1.nid3_config: 0x18560010 as=1 seq=0 device=Digital-out conn=Jack
ctype=Digital loc=0x18 color=Unknown misc=0
dev.hdaa.1.nid3: pin: Digital-out (Jack)
Widget cap: 0x0040778d PWR DIGITAL UNSOL 8CH
Association: 0 (0x0001)
Pin cap: 0x0994 PDC OUT HDMI DP HBR
Pin config: 0x18560010 as=1 seq=0 device=Digital-out conn=Jack
ctype=Digital loc=0x18 color=Unknown misc=0
Pin control: 0x0040 OUT
Output amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
Connections: 1
+ <- nid=2 [audio output]
dev.hdaa.1.nid2: audio output
Widget cap: 0x6611 PWR DIGITAL 8CH
Association: 0 (0x0001)
OSS: pcm (pcm)
Stream cap: 0x0005 AC3 PCM
PCM cap: 0x001a07f0 16 24 32 bits, 32 44 48 88 96 176 192 KHz
dev.hdaa.1.%parent: hdacc1
dev.hdaa.1.%pnpinfo: type=0x01 subsystem=0x80860101
dev.hdaa.1.%location: nid=1
dev.hdaa.1.%driver: hdaa
dev.hdaa.1.%desc: Intel Kabylake Audio Function Group
dev.hdaa.0.reconfig: 0
dev.hdaa.0.gpo_config:
dev.hdaa.0.gpo_state:
dev.hdaa.0.gpio_config: 0=set 1=keep 2=keep
dev.hdaa.0.gpio_state: 0=output(1) 1=disabled 2=disabled
dev.hdaa.0.gpi_state:
dev.hdaa.0.config:
forcestereo,ivref50,ivref80,ivref100,ivref,vref
dev.hdaa.0.nid35: audio
mixer
Widget cap: 0x0020010b
STEREO
Association: 2 (0x0001)
OSS: speaker, monitor
Input amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
Connections: 7
+ [DISABLED] <- nid=24 [pin: Speaker (None)] [DISABLED]
+ [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED]
+ [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED]
+ [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED]
+ <- nid=29 [beep widget]
+ <- nid=11 [audio mixer]
+ <- nid=18 [pin: Mic (Fixed)]
dev.hdaa.0.nid34: audio mixer [DISABLED]
Widget cap: 0x0020010b STEREO
Input amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
Connections: 6
+ [DISABLED] <- nid=24 [pin: Speaker (None)] [DISABLED]
+ [DISABLED] <- nid=25 [pin: Speaker (None)] [DISABLED]
+ [DISABLED] <- nid=26 [pin: Speaker (None)] [DISABLED]
+ [DISABLED] <- nid=27 [pin: Speaker (None)] [DISABLED]
+ [DISABLED] <- nid=29 [beep widget]
+ [DISABLED] <- nid=11 [audio mixer]
dev.hdaa.0.nid33_original: 0x02211030 as=3 seq=0 device=Headphones
conn=Jack ctype=1/8 loc=Front color=Black misc=0
dev.hdaa.0.nid33_config: 0x02211030 as=3 seq=0 device=Headphones conn=Jack
ctype=1/8 loc=Front color=Black misc=0
dev.hdaa.0.nid33: pin: Headphones (Black Jack)
Widget cap: 0x0040058d PWR UNSOL STEREO
Association: 1 (0x0001)
Pin cap: 0x0001001c PDC HP OUT EAPD
Re: Sound issues with Dell Latitude 7490 (kabylake)
On 10/3/18 6:19 PM, Mario Lobo wrote:
Em qua, 3 de out de 2018 às 10:10, David Wolfskill
mailto:da...@catwhisker.org>> escreveu:
On Mon, Oct 01, 2018 at 11:12:25PM +0200, Jakob Alvermark wrote:
>
> Do the headphones work with this patch?
>
> Index: sys/dev/sound/pci/hda/hdaa.c
> ===
> --- sys/dev/sound/pci/hda/hdaa.c (revision 339076)
> +++ sys/dev/sound/pci/hda/hdaa.c (working copy)
> @@ -5034,11 +5034,13 @@
> pincap = w->wclass.pin.cap;
>
> /* Disable everything. */
> + /*
> w->wclass.pin.ctrl &= ~(
> HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
> HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
> HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
> HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
> + */
>
> if (w->enable == 0) {
> /* Pin is unused so left it disabled. */
>
Thank you! This addressed the long-standing (Reported: 2015-05-29
21:15 UTC) issue I have had with my laptop (Dell Precision M4800), as
documented in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200526
-- now updated to reflect the fix.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Trump is gaslighting us:
https://www.bbc.com/news/world-us-canada-44959300
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Thank you #2 !! The patch fixed my weird headphone sound too on
11.2-STABLE!
I still can't make the plugging-in switch work but it's ok. I created
scripts for that with
Can you send the output from 'sysctl dev.hdaa'?
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sound issues with Dell Latitude 7490 (kabylake)
Em qua, 3 de out de 2018 às 10:10, David Wolfskill
escreveu:
> On Mon, Oct 01, 2018 at 11:12:25PM +0200, Jakob Alvermark wrote:
> >
> > Do the headphones work with this patch?
> >
> > Index: sys/dev/sound/pci/hda/hdaa.c
> > ===
> > --- sys/dev/sound/pci/hda/hdaa.c(revision 339076)
> > +++ sys/dev/sound/pci/hda/hdaa.c(working copy)
> > @@ -5034,11 +5034,13 @@
> > pincap = w->wclass.pin.cap;
> >
> > /* Disable everything. */
> > +/*
> > w->wclass.pin.ctrl &= ~(
> > HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
> > HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
> > HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
> > HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
> > +*/
> >
> > if (w->enable == 0) {
> > /* Pin is unused so left it disabled. */
> >
>
> Thank you! This addressed the long-standing (Reported: 2015-05-29
> 21:15 UTC) issue I have had with my laptop (Dell Precision M4800), as
> documented in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200526
> -- now updated to reflect the fix.
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>
Thank you #2 !! The patch fixed my weird headphone sound too on 11.2-STABLE!
I still can't make the plugging-in switch work but it's ok. I created
scripts for that with
/sbin/sysctl hw.snd.default_unit=1 (headphones) or 0 speakers.
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio YET!!]
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: which way to update export_args structure?
On Wed, Oct 03, 2018 at 12:40:27AM +, Rick Macklem wrote:
> Hi,
>
> I am working on updating "struct export_args" to fix/add a few things.
> One of these is that "ex_flags" is an int, but the flags are defined in
> mount.h
> as MNT_xx bits that now exceed 32bits (mnt_flag is now uint64_t).
> For now, this doesn't break anything, since the flags used by ex_flags are
> all defined in the low order 32bits but...it seems like this should be
> addressed
> by a new version of "struct export_args".
>
> I have two versions of the updated structure:
> A)
> struct export_args {
> uint64_t ex_flags; /* export related flags */
> uid_t ex_root;/* mapping for root uid */
> struct xucred ex_anon; /* mapping for anonymous user */
> struct sockaddr *ex_addr; /* net address to which exported */
> u_char ex_addrlen; /* and the net address length */
> struct sockaddr *ex_mask; /* mask of valid bits in saddr */
> u_char ex_masklen; /* and the smask length */
> char*ex_indexfile; /* index file for WebNFS URLs */
> int ex_numsecflavors; /* security flavor count */
> int ex_secflavors[MAXSECFLAVORS]; /* list of security flavors */
> int32_t ex_fsid;/* mnt_stat.f_fsid.val[0] if */
> /* MNT_EXPORTFSID set in ex_flags64 */
> gid_t *ex_suppgroups; /* Supplemental groups if */
> /* ex_anon.cr_ngroups > XU_NGROUPS */
> };
> B)
> struct export_args {
> int ex_flags; /* export related flags */
> uid_t ex_root;/* mapping for root uid */
> struct xucred ex_anon; /* mapping for anonymous user */
> struct sockaddr *ex_addr; /* net address to which exported */
> u_char ex_addrlen; /* and the net address length */
> struct sockaddr *ex_mask; /* mask of valid bits in saddr */
> u_char ex_masklen; /* and the smask length */
> char*ex_indexfile; /* index file for WebNFS URLs */
> int ex_numsecflavors; /* security flavor count */
> int ex_secflavors[MAXSECFLAVORS]; /* list of security flavors */
> uint64_t ex_flagshighbits; /* High order bits of mnt_flag */
> int32_t ex_fsid;/* mnt_stat.f_fsid.val[0] if */
> /* MNT_EXPORTFSID set in ex_flags64 */
> gid_t *ex_suppgroups; /* Supplemental groups if */
> /* ex_anon.cr_ngroups > XU_NGROUPS */
> };
>
> A) does the obvious thing. Unfortunately, this changes the vfs KABI
> (specifically the function vfs_oexport_conv()) such that a file system
> module compiled with an unpatched mount.h could crash a patched system.
> As such, I think it couldn't be MFC'd and would be stuck in head/current
> until FreeBSD13 (or FreeBSD14 if 13 gets skipped over;-).
>
> B) doesn't change any fields, but adds a second ex_flagshighbits for the high
> order bit. Since it only adds fields where none of those bits are used after
> the exports are processed by vfs_export() and, as such, will not break
> the VFS KABI, since vfs_domount_update() differentiates which version
> of export_args is being used.
> As such, I believe this version can be MFC'd. However, it does seem confusing
> to have the two ex_flags fields for the low and high 32bits.
I see you've found a way to do compatibility for a new ABI. If you
wanted to avoid changing the struct size, there is 3 bytes of usable
padding after each ex_addrlen and ex_masklen.
One general question: why does export_args still exist as an interface
between userspace and the kernel? It's passed via nmount so it seems
like the individual entries should be elements in the vector instead.
This would be much friendlier if one wanted to do 32-bit compat support
for mountd.
-- Brooks
signature.asc
Description: PGP signature
Re: debugging a run of poudriere-bulk
El día miércoles, octubre 03, 2018 a las 01:41:14p. m. +0200, Matthias Apitz escribió: > > Hello, > > > I'm trying to nail down PR 231532 of a port which fails to build in > poudriere. In the last phase of the ports build, while creating the pkg > of the built port with pkg-static, this crashes: When I do run pudriere bulk with -vv options, it says only: [00:02:40] [01] [00:01:51] Status x11/kde-workspace-kde4 | kde-workspace-kde4-4.11.22_26: build [00:10:41] [01] [00:09:52] Status x11/kde-workspace-kde4 | kde-workspace-kde4-4.11.22_26: run-depends [00:10:46] [01] [00:09:57] Status x11/kde-workspace-kde4 | kde-workspace-kde4-4.11.22_26: stage [00:11:42] [01] [00:10:53] Status x11/kde-workspace-kde4 | kde-workspace-kde4-4.11.22_26: package [00:11:46] [01] [00:10:57] Finished x11/kde-workspace-kde4 | kde-workspace-kde4-4.11.22_26: Failed: package [00:11:46] Stopping 1 builders matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October 3: Day of German Unity? No! Day of taking over the GDR. 3. Oktober: Tag der Deutschen Einheit? Nein! DDR-Anschlusstag. signature.asc Description: PGP signature
Re: which way to update export_args structure?
Gary Jennejohn wrote: [stuff snipped] >In B, shouldn't ex_flags become uint32_t if all 32 bits can contain >flag bits? You could. For B) my intent was to leave the structure exactly the same as the old versions and only add new fields at the end. The current compatibility code in head does bcopy() of the structure, which means a change to uint32_t would require that to be re-written. (For A) it gets re-written anyhow.) > And why make ex_flagshighbits a uint64_t? You could >make it uint32_t and simply shift the high bits around. Again, you could. I didn't do that, since the code then does require bit shifts every time you test a flag and I thought that would look messy. I also get worried that compilers will do weird things like truncate the constant to 32bits before the shift and drop the flag. (I do test cases for these in a little program, but can only test i386.) (The flags are constants defined in mount.h as MNT_xx for 64bits.) Since I figured out a way that I think allows A) to be MFC'd, I'm leaning towards A) anyhow. rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sound issues with Dell Latitude 7490 (kabylake)
On Wed, Oct 3, 2018 at 2:30 PM Jakob Alvermark wrote:
> On 10/3/18 3:06 PM, David Wolfskill wrote:
> > On Mon, Oct 01, 2018 at 11:12:25PM +0200, Jakob Alvermark wrote:
> >>
> >> Do the headphones work with this patch?
> >>
> >> Index: sys/dev/sound/pci/hda/hdaa.c
> >> ===
> >> --- sys/dev/sound/pci/hda/hdaa.c(revision 339076)
> >> +++ sys/dev/sound/pci/hda/hdaa.c(working copy)
> >> @@ -5034,11 +5034,13 @@
> >>pincap = w->wclass.pin.cap;
> >>
> >>/* Disable everything. */
> >> +/*
> >>w->wclass.pin.ctrl &= ~(
> >>HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
> >>HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
> >>HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
> >>HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
> >> +*/
> >>
> >>if (w->enable == 0) {
> >>/* Pin is unused so left it disabled. */
> >>
> > Thank you! This addressed the long-standing (Reported: 2015-05-29
> > 21:15 UTC) issue I have had with my laptop (Dell Precision M4800), as
> > documented in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200526
> > -- now updated to reflect the fix.
>
>
> That's great! Glad to hear it helped.
>
> This is probably not a proper fix, but it helps to understand the problem.
>
> Could you post the output of 'sysctl dev.hdaa' with and without the
> patch so we can see what's different?
>
>
Hi Jakob
Here's my diff from orig to patched (full output zipped and attached)
johannes@jm:~ % diff -u -U5 tmp/dev_hdaa_0_orig.txt
tmp/dev_hdaa_0_patched.txt
--- tmp/dev_hdaa_0_orig.txt2018-10-03 14:32:31.264778000 +0100
+++ tmp/dev_hdaa_0_patched.txt2018-10-03 14:28:18.767561000 +0100
@@ -58,11 +58,11 @@
dev.hdaa.0.nid30_config: 0x421212f2 as=15 seq=2 device=Speaker conn=None
ctype=1/4 loc=Front color=Black misc=2
dev.hdaa.0.nid30: pin: Speaker (None) [DISABLED]
Widget cap: 0x00400781 PWR DIGITAL UNSOL STEREO
Pin cap: 0x0014 PDC OUT
Pin config: 0x421212f2 as=15 seq=2 device=Speaker conn=None ctype=1/4
loc=Front color=Black misc=2
-Pin control: 0x
+Pin control: 0x0040 OUT
Connections: 1
+ <- nid=6 [audio output] [DISABLED]
dev.hdaa.0.nid29_original: 0x4071 as=0 seq=1 device=Modem-handset
conn=None ctype=Unknown loc=0x00 color=Unknown misc=0
dev.hdaa.0.nid29_config: 0x4071 as=0 seq=1 device=Modem-handset
conn=None ctype=Unknown loc=0x00 color=Unknown misc=0
@@ -81,11 +81,11 @@
dev.hdaa.0.nid27_config: 0x41f0 as=15 seq=0 device=Speaker conn=None
ctype=1/8 loc=Rear color=Black misc=1
dev.hdaa.0.nid27: pin: Speaker (None) [DISABLED]
Widget cap: 0x0040058f PWR UNSOL STEREO
Pin cap: 0x00013734 PDC OUT IN VREF[ 50 80 100 GROUND HIZ ] EAPD
Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
loc=Rear color=Black misc=1
-Pin control: 0x
+Pin control: 0x0020 IN
EAPD: 0x0002 EAPD
Output amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
Connections: 2
+ [DISABLED] <- nid=2 [audio output] (selected)
@@ -104,20 +104,20 @@
dev.hdaa.0.nid25_config: 0x41f0 as=15 seq=0 device=Speaker conn=None
ctype=1/8 loc=Rear color=Black misc=1
dev.hdaa.0.nid25: pin: Speaker (None) [DISABLED]
Widget cap: 0x0040048b PWR UNSOL STEREO
Pin cap: 0x3724 PDC IN VREF[ 50 80 100 GROUND HIZ ]
Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
loc=Rear color=Black misc=1
-Pin control: 0x
+Pin control: 0x0020 IN
Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
dev.hdaa.0.nid24_original: 0x41f0 as=15 seq=0 device=Speaker conn=None
ctype=1/8 loc=Rear color=Black misc=1
dev.hdaa.0.nid24_config: 0x41f0 as=15 seq=0 device=Speaker conn=None
ctype=1/8 loc=Rear color=Black misc=1
dev.hdaa.0.nid24: pin: Speaker (None) [DISABLED]
Widget cap: 0x0040048b PWR UNSOL STEREO
Pin cap: 0x3724 PDC IN VREF[ 50 80 100 GROUND HIZ ]
Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
loc=Rear color=Black misc=1
-Pin control: 0x
+Pin control: 0x0020 IN
Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
dev.hdaa.0.nid23: vendor widget [DISABLED]
Widget cap: 0x00f0
> Jakob
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
<>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sound issues with Dell Latitude 7490 (kabylake)
On 10/3/18 3:06 PM, David Wolfskill wrote:
On Mon, Oct 01, 2018 at 11:12:25PM +0200, Jakob Alvermark wrote:
Do the headphones work with this patch?
Index: sys/dev/sound/pci/hda/hdaa.c
===
--- sys/dev/sound/pci/hda/hdaa.c (revision 339076)
+++ sys/dev/sound/pci/hda/hdaa.c (working copy)
@@ -5034,11 +5034,13 @@
pincap = w->wclass.pin.cap;
/* Disable everything. */
+ /*
w->wclass.pin.ctrl &= ~(
HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
+ */
if (w->enable == 0) {
/* Pin is unused so left it disabled. */
Thank you! This addressed the long-standing (Reported: 2015-05-29
21:15 UTC) issue I have had with my laptop (Dell Precision M4800), as
documented in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200526
-- now updated to reflect the fix.
That's great! Glad to hear it helped.
This is probably not a proper fix, but it helps to understand the problem.
Could you post the output of 'sysctl dev.hdaa' with and without the
patch so we can see what's different?
Jakob
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sound issues with Dell Latitude 7490 (kabylake)
On Mon, Oct 01, 2018 at 11:12:25PM +0200, Jakob Alvermark wrote:
>
> Do the headphones work with this patch?
>
> Index: sys/dev/sound/pci/hda/hdaa.c
> ===
> --- sys/dev/sound/pci/hda/hdaa.c (revision 339076)
> +++ sys/dev/sound/pci/hda/hdaa.c (working copy)
> @@ -5034,11 +5034,13 @@
> pincap = w->wclass.pin.cap;
>
> /* Disable everything. */
> + /*
> w->wclass.pin.ctrl &= ~(
> HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
> HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
> HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
> HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
> + */
>
> if (w->enable == 0) {
> /* Pin is unused so left it disabled. */
>
Thank you! This addressed the long-standing (Reported: 2015-05-29
21:15 UTC) issue I have had with my laptop (Dell Precision M4800), as
documented in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200526
-- now updated to reflect the fix.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
debugging a run of poudriere-bulk
Hello, I'm trying to nail down PR 231532 of a port which fails to build in poudriere. In the last phase of the ports build, while creating the pkg of the built port with pkg-static, this crashes: # tail /usr/local/poudriere/data/logs/bulk/freebsd-r338641-ports-20180920/2018-10-03_11h32m17s/logs/kde-workspace-kde4-4.11.22_26.log Child process pid=85086 terminated abnormally: Segmentation fault *** Error code 1 Stop. make: stopped in /usr/ports/x11/kde-workspace-kde4 =>> Cleaning up wrkdir # grep 85086 /var/log/messages Oct 3 11:44:01 jet kernel: pid 85086 (pkg-static), uid 65534: exited on signal 11 How can I enter the jail interactively in the moment after the crash to rerun and debug pkg-static? When I run 'poudriere bulk -i ...' the port builds fine: # poudriere bulk -i -J 1 -j freebsd-r338641 -p ports-20180920 x11/kde-workspace-kde4 # cd /usr/ports/x11/kde-workspace-kde4 # make package gmake[1]: Leaving directory '/wrkdirs/usr/ports/x11/kde-workspace-kde4/work/.build' install -l rs /wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/bin/startkde /wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/bin/startkde4 /bin/mkdir -p /wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/share/xsessions install -m 0644 /usr/ports/x11/kde-workspace-kde4/files/kde4.desktop /wrkdirs/usr/ports/x11/kde-workspace-kde4/work/stage/usr/local/share/xsessions > Compressing man pages (compress-man) ===> Staging rc.d startup script(s) ===> Building package for kde-workspace-kde4-4.11.22_26 cp: /packages/All/kde-workspace-kde4-4.11.22_26.txz: Read-only file system *** Error code 1 Stop. make: stopped in /usr/ports/x11/kde-workspace-kde4 # cd /usr/ports/x11/kde-workspace-kde4 # ls -l total 42 -rw-r--r-- 1 root wheel5480 Sep 20 05:16 Makefile -rw-r--r-- 1 root wheel 225 Sep 20 05:16 distinfo drwxr-xr-x 2 root wheel 30 Sep 20 05:16 files -rw-r--r-- 1 root wheel 219 Sep 20 05:16 pkg-descr -rw-r--r-- 1 root wheel 100336 Sep 20 05:16 pkg-plist # ls -la /wrkdirs/usr/ports/x11/kde-workspace-kde4/work/pkg total 17921 drwxr-xr-x 2 root wheel64 Oct 3 09:13 . drwxr-xr-x 7 root wheel 960 Oct 3 09:13 .. -rw-r--r-- 1 root wheel 18346688 Oct 3 09:13 kde-workspace-kde4-4.11.22_26.txz # scp -p /wrkdirs/usr/ports/x11/kde-workspace-kde4/work/pkg/kde-workspace-kde4-4.11.22_26.txz guru@192.168.2.35:/tmp -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 13. August 2018: Ich würde gern einen AUSREISEANTRAG stellen. August 13, 2018: I'd like to ask for an exit permit of this country. signature.asc Description: PGP signature
Re: linux-c7 and opengl apps?
On Wed, Oct 3, 2018 at 5:40 PM Johannes Lundberg wrote: > Hi > > Have anyone successfully run opengl apps with linux-c7? > > Linux opengl apps works great with linux-c6 on gpu < kabylake but > linux-c6-dri does not include support for kabylake gpus. > Linux glxinfo in c7 show support for hardware rendering on kabylake but any > attempt to run an opengl app results in application seg fault or other > crash (I believe this is also the case with skylake gpus on linux-c7). > > Is there any way to run gdb on linux apps/core dumps? > > /Johannes > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Highly unlikely since the Linux kernel memory model is pretty different than FreeBSD especially concerning graphics. Linux kernel graphics will have to use dma regions or the low kernel memory while most other stuff hangs out in the high kernel memory. Since the graphics drivers have to have contiguous memory regions that should not be swapped out, if linuxkpi doesn't manage these complexities you'll continue to random failures especially around sleep to wake, context switching and power management. It can be fixed though, you'll just need to port the entire Linux memory architecture to FreeBSD and that's as it stands right now. Don't look into rma, numa, hhm, huge pages and all the other lovely memory features that is currently mainline or about to get merged into mainline. Good luck with that though. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
linux-c7 and opengl apps?
Hi Have anyone successfully run opengl apps with linux-c7? Linux opengl apps works great with linux-c6 on gpu < kabylake but linux-c6-dri does not include support for kabylake gpus. Linux glxinfo in c7 show support for hardware rendering on kabylake but any attempt to run an opengl app results in application seg fault or other crash (I believe this is also the case with skylake gpus on linux-c7). Is there any way to run gdb on linux apps/core dumps? /Johannes ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: which way to update export_args structure?
On Wed, 3 Oct 2018 00:40:27 +
Rick Macklem wrote:
> Hi,
>
> I am working on updating "struct export_args" to fix/add a few things.
> One of these is that "ex_flags" is an int, but the flags are defined in
> mount.h
> as MNT_xx bits that now exceed 32bits (mnt_flag is now uint64_t).
> For now, this doesn't break anything, since the flags used by ex_flags are
> all defined in the low order 32bits but...it seems like this should be
> addressed
> by a new version of "struct export_args".
>
> I have two versions of the updated structure:
> A)
> struct export_args {
> uint64_t ex_flags; /* export related flags */
> uid_t ex_root;/* mapping for root uid */
> struct xucred ex_anon; /* mapping for anonymous user */
> struct sockaddr *ex_addr; /* net address to which exported */
> u_char ex_addrlen; /* and the net address length */
> struct sockaddr *ex_mask; /* mask of valid bits in saddr */
> u_char ex_masklen; /* and the smask length */
> char*ex_indexfile; /* index file for WebNFS URLs */
> int ex_numsecflavors; /* security flavor count */
> int ex_secflavors[MAXSECFLAVORS]; /* list of security flavors */
> int32_t ex_fsid;/* mnt_stat.f_fsid.val[0] if */
> /* MNT_EXPORTFSID set in ex_flags64 */
> gid_t *ex_suppgroups; /* Supplemental groups if */
> /* ex_anon.cr_ngroups > XU_NGROUPS */
> };
> B)
> struct export_args {
> int ex_flags; /* export related flags */
> uid_t ex_root;/* mapping for root uid */
> struct xucred ex_anon; /* mapping for anonymous user */
> struct sockaddr *ex_addr; /* net address to which exported */
> u_char ex_addrlen; /* and the net address length */
> struct sockaddr *ex_mask; /* mask of valid bits in saddr */
> u_char ex_masklen; /* and the smask length */
> char*ex_indexfile; /* index file for WebNFS URLs */
> int ex_numsecflavors; /* security flavor count */
> int ex_secflavors[MAXSECFLAVORS]; /* list of security flavors */
> uint64_t ex_flagshighbits; /* High order bits of mnt_flag */
> int32_t ex_fsid;/* mnt_stat.f_fsid.val[0] if */
> /* MNT_EXPORTFSID set in ex_flags64 */
> gid_t *ex_suppgroups; /* Supplemental groups if */
> /* ex_anon.cr_ngroups > XU_NGROUPS */
> };
>
> A) does the obvious thing. Unfortunately, this changes the vfs KABI
> (specifically the function vfs_oexport_conv()) such that a file system
> module compiled with an unpatched mount.h could crash a patched system.
> As such, I think it couldn't be MFC'd and would be stuck in head/current
> until FreeBSD13 (or FreeBSD14 if 13 gets skipped over;-).
>
> B) doesn't change any fields, but adds a second ex_flagshighbits for the high
> order bit. Since it only adds fields where none of those bits are used after
> the exports are processed by vfs_export() and, as such, will not break
> the VFS KABI, since vfs_domount_update() differentiates which version
> of export_args is being used.
> As such, I believe this version can be MFC'd. However, it does seem confusing
> to have the two ex_flags fields for the low and high 32bits.
>
> So, which do you think it preferable? rick
> ps: Josh Paetzel has volunteered to do the mountd.c changes and I have a kerne
> patch that I'll put up on phabricator once Josh has been able to test
> it.
>
In B, shouldn't ex_flags become uint32_t if all 32 bits can contain
flag bits? And why make ex_flagshighbits a uint64_t? You could
make it uint32_t and simply shift the high bits around.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
