Re: CFR: extend use of nitems() macro in the kernel.

[Pedro Giffuni]

On 04/18/16 13:27, John Baldwin wrote:

On Saturday, April 16, 2016 01:25:09 PM Pedro Giffuni wrote:

Hello;

Using coccinelle, and some hand re-formatting, I generated a patch to
make use of the nitems() macro in sys, which is too big for
phabricator [1].

I was careful to exclude anything from the contrib directory or
any code that is shared with userland (as to not have to include
additional headers).

The patch is big but pretty safe, I think. The changes are small but
still it touches many files[1].

I would like some feedback on the convenience of doing such replacement.
If it is a good idea we could do the same for roundup2() and, in fact,
I think DragonFly has already done this.

Regards,

Pedro.

[1] https://people.freebsd.org/~pfg/patches/sys-nitems.diff

[2] For those too lazy to check [1], here is a list of affected files.

M   sys/amd64/amd64/amd64_mem.c
M   sys/amd64/amd64/machdep.c
M   sys/amd64/linux/linux_sysvec.c
M   sys/amd64/linux32/linux32_sysvec.c
M   sys/arm/amlogic/aml8726/aml8726_clkmsr.c
M   sys/arm/arm/db_interface.c
M   sys/arm/at91/at91_pmc.c
M   sys/arm/mv/armadaxp/armadaxp.c
M   sys/arm/ti/cpsw/if_cpsw.c
M   sys/arm/xscale/ixp425/ixp425.c
M   sys/boot/common/part.c
M   sys/boot/efi/loader/bootinfo.c
M   sys/boot/mips/beri/boot2/boot2.c
M   sys/boot/uboot/common/metadata.c
M   sys/cam/ata/ata_da.c
M   sys/cam/ata/ata_xpt.c


I would perhaps remove ata_quirk_table_size entirely and replace its
use with nitems() directly.  Probably best if that was a separate commit
though from the near-mechanical replacement.


M   sys/cam/cam.c


Same here.  num_cam_status_entries is only used in one place and I think
directly using nitems() is probably clearer overall.


M   sys/cam/scsi/scsi_all.c


Possibly the same here with sense_key_table_size.


M   sys/cam/scsi/scsi_cd.c
M   sys/cam/scsi/scsi_da.c
M   sys/cam/scsi/scsi_sa.c
M   sys/cam/scsi/scsi_xpt.c


Same as for ata_quirk_table_size (ironically this used the size in one
place and the expanded form of nitems in another while the ata variant
at least used the size in both places).


M   sys/cam/scsi/smp_all.c
M   sys/compat/linux/linux_socket.c
M   sys/ddb/db_variables.c
M   sys/dev/adb/adb_kbd.c
M   sys/dev/advansys/adv_isa.c
M   sys/dev/advansys/advlib.c
M   sys/dev/advansys/adw_pci.c


Same here for num adw_num_pci_devs (only used once)


M   sys/dev/advansys/adwlib.c


Probably the same here for adw_num_sync_rates (used twice).


M   sys/dev/ae/if_ae.c


Same here for AE_DEVS_COUNT (only used once).


M   sys/dev/age/if_age.c
M   sys/dev/agp/agp.c
M   sys/dev/agp/agp_ali.c
M   sys/dev/agp/agp_amd64.c
M   sys/dev/aha/aha_isa.c
M   sys/dev/aic/aic.c
M   sys/dev/aic/aic_cbus.c


Same here for AIC_ISA_NUMPORTS (only used once).


M   sys/dev/aic/aic_isa.c


As above.


M   sys/dev/ale/if_ale.c
M   sys/dev/altera/atse/if_atse.c
M   sys/dev/atkbdc/atkbd.c
M   sys/dev/atkbdc/atkbdc.c
M   sys/dev/atkbdc/psm.c
M   sys/dev/bktr/bktr_core.c
M   sys/dev/bwi/bwirf.c
M   sys/dev/bwn/if_bwn.c
M   sys/dev/cardbus/cardbus_cis.c
M   sys/dev/digi/digi.c
M   sys/dev/digi/digi_isa.c
M   sys/dev/dwc/if_dwc.c
M   sys/dev/ed/if_ed_hpp.c
M   sys/dev/ed/if_ed_isa.c
M   sys/dev/ed/if_ed_pci.c
M   sys/dev/fb/creator.c


Same here for CREATOR_FB_MAP_SIZE (only used once).


M   sys/dev/fb/fb.c
M   sys/dev/fb/machfb.c
M   sys/dev/fb/vesa.c
M   sys/dev/fb/vga.c
M   sys/dev/flash/mx25l.c
M   sys/dev/hatm/if_hatm.c
M   sys/dev/hifn/hifn7751.c
M   sys/dev/hwpmc/hwpmc_amd.c


Same here for amd_event_codes_size (only used twice).


M   sys/dev/hwpmc/hwpmc_core.c


Same here for niap_events.


M   sys/dev/hwpmc/hwpmc_e500.c


e500_event_codes_size isn't even used.  It should just be removed.


M   sys/dev/hwpmc/hwpmc_mips24k.c
M   sys/dev/hwpmc/hwpmc_mips74k.c
M   sys/dev/hwpmc/hwpmc_mpc7xxx.c


Same here for mpc7xxx_event_codes_size.


M   sys/dev/hwpmc/hwpmc_octeon.c
M   sys/dev/hwpmc/hwpmc_uncore.c


Same here for nucp_events.


M   sys/dev/hwpmc/hwpmc_xscale.c


Same here for xscale_event_codes_size.


M   sys/dev/if_ndis/if_ndis.c
M   sys/dev/jme/if_jme.c
M   sys/dev/kbd/kbd.c
M   sys/dev/le/if_le_isa.c
M   sys/dev/le/if_le_lebuffer.c


Same here for NLEMEDIA (only used once).


M   sys/dev/le/if_le_ledma.c
M   sys/dev/mlx/mlx.c
M   sys/dev/mxge/if_mxge.c
M   sys/dev/nand/nand_id.c
M   sys/dev/ncr/ncr.c
M   sys/dev/nctgpio/nctgpio.c
M   sys/dev/nfe/if_nfe.c
M   sys/dev/patm/if_patm_attach.c
M   sys/dev/pccard/pccard_cis_quirks.c


Same here for n_pccard_cis_quirks (only used once).


M   sys/dev/rc/rc.c
M   sys/dev/re/if_re.c
M   sys/dev/rl/if_rl.c
M   sys/dev/rndtest/rndtest.c


Same here for RNDTEST_NTESTS 

Re: extremely slow to get to loader

[Allan Jude]

On 2016-04-21 10:46, Johannes Dieterich wrote:
> Dear all,
> 
> with r298385, I observe extremely long times from turning on my laptop
> to reach loader. This is a regression compared to a roughly 1 week old
> CURRENT.
> 
> This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup.
> 
> Please let me know how I can help to solve this issue.
> 
> Thanks,
> 
> 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"
> 

Can you describe where exactly it is slow?

Once you get to the loader menu (the beastie menu), can you choose the
option to go to the loader prompt, and type:
bcachestat

And provide the output of that.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

[Solved] [WAS:libc build error] Mostly all solved bw-iw-ik from 4-20-2016

[Jeffrey Bouquet]

On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> 
> 
> On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" 
>  wrote:
> 
> > 
> > 
> > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude  
> > wrote:
> > 
> > > On 2016-04-20 12:06, Jeffrey Bouquet wrote:
> > > > unistd
> > > > 
> > > > 
> > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected 
> > > > function body after function declarator
> > > > intexecl(  .
> > > >  332:46:
> > > > same...
> > > > 
> > > > stops libc
> > > > otherwise clang36 seems to be building so far, if it builds unsure 
> > > > about installworld
> > > > ___
> > > > 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"
> > > > 
> > > 
> > > The mailing list strips attachments. Can you upload it somewhere and
> > > provide a link
> > > 
> > > -- 
> > > Allan Jude
> > > ___
> > > 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"
> > 
> > 
> > Well, it is now r298350 Wed Apr 20...
> > However several problems
> > 
> > SINGLE-USER BOOT PROBLEMS
> > 1... usual boot fails, this is single-user adjusted, but I cannot add swap 
> > (swapon? swapctl?)
> > 1a...  the last time, it was fixed with using the old /kernel ... 
> > 
> > multi-user boot problems
> > 
> > 2... the last usual boot dumped with vm_pager or something,  verbose boot 
> > times out with xpt_config not completing.
> > 2a could be a wrong setting is loader.conf, the nvidia.ko not yet 
> > updated (which it now is ) for the latter
> >   case I have yet to reboot to test
> >   2b...   Reboot to test takes longer, /rescue/mount each filesystem 
> > individually... 
> > 
> > 
> > As one might surmise, I'd rather see buildworld made more foolproof than 
> > other recent improvements 
> > (pkg, zfs, ...)
> 
> From backup, I have r288246 kernel and nvidia.ko  (v11)
> from source, I have world and all except those TWO files at r298350 )(v11), 
> nvidia (newer) won't load with older kernel
> A few at-boot scripts no longer work as expected... but no other major 
> problems (swap is present again)
> (multi-user boot works) 
> 
> Best practice maybe to update the kernel?  It is a custom one from way back 
> in 2004 initially
> without sound drivers and without debug symbols...  and many esoteric lines 
> added which I cobbled
> together at first then changed per diffs of GENERIC over the years...
> 
> Thanks for any known methods
> 
> J. Bouquet
> ___
> 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"


Updated to a slightly-less-than-full GENERIC.  Still dumped core.  Moved 
loader.conf out of
the way, works fine.  What will take some time now is moving loader.conf back 
piece by piece
[until/if there is/ever was a utility to do it for us... ] to find the 
problematic line or two, then
resume testing of the install of the custom kernel that also is 'fail' status 
at this point... unless/until
I decide to also test it, THEN resume the loader.conf line-by-line back in...

tl;dr   loader.conf problematic line and maybe an additional unknown in either 
kernel text file.
___
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: Re: Installworld, BW, IK fixed, here are the in > out loader.conf lines

[Jeffrey Bouquet]

On Thu, 21 Apr 2016 13:29:59 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> 
> 
> On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" 
>  wrote:
> 
> > 
> > 
> > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" 
> >  wrote:
> > 
> > > 
> > > 
> > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude  
> > > wrote:
> > > 
> > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote:
> > > > > unistd
> > > > > 
> > > > > 
> > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected 
> > > > > function body after function declarator
> > > > > intexecl(  .
> > > > >  332:46:
> > > > > same...
> > > > > 
> > > > > stops libc
> > > > > otherwise clang36 seems to be building so far, if it builds unsure 
> > > > > about installworld
> > > > > ___
> > > > > 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"
> > > > > 
> > > > 
> > > > The mailing list strips attachments. Can you upload it somewhere and
> > > > provide a link
> > > > 
> > > > -- 
> > > > Allan Jude
> > > > ___
> > > > 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"
> > > 
> > > 
> > > Well, it is now r298350 Wed Apr 20...
> > > However several problems
> > > 
> > > SINGLE-USER BOOT PROBLEMS
> > > 1... usual boot fails, this is single-user adjusted, but I cannot add 
> > > swap (swapon? swapctl?)
> > > 1a...  the last time, it was fixed with using the old /kernel ... 
> > > 
> > > multi-user boot problems
> > > 
> > > 2... the last usual boot dumped with vm_pager or something,  verbose boot 
> > > times out with xpt_config not completing.
> > > 2a could be a wrong setting is loader.conf, the nvidia.ko not yet 
> > > updated (which it now is ) for the latter
> > >   case I have yet to reboot to test
> > >   2b...   Reboot to test takes longer, /rescue/mount each filesystem 
> > > individually... 
> > > 
> > > 
> > > As one might surmise, I'd rather see buildworld made more foolproof than 
> > > other recent improvements 
> > > (pkg, zfs, ...)
> > 
> > From backup, I have r288246 kernel and nvidia.ko  (v11)
> > from source, I have world and all except those TWO files at r298350 )(v11), 
> > nvidia (newer) won't load with older kernel
> > A few at-boot scripts no longer work as expected... but no other major 
> > problems (swap is present again)
> > (multi-user boot works) 
> > 
> > Best practice maybe to update the kernel?  It is a custom one from way back 
> > in 2004 initially
> > without sound drivers and without debug symbols...  and many esoteric lines 
> > added which I cobbled
> > together at first then changed per diffs of GENERIC over the years...
> > 
> > Thanks for any known methods
> > 
> > J. Bouquet
> > ___
> > 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"
> 
> 
> Updated to a slightly-less-than-full GENERIC.  Still dumped core.  Moved 
> loader.conf out of
> the way, works fine.  What will take some time now is moving loader.conf back 
> piece by piece
> [until/if there is/ever was a utility to do it for us... ] to find the 
> problematic line or two, then
> resume testing of the install of the custom kernel that also is 'fail' status 
> at this point... unless/until
> I decide to also test it, THEN resume the loader.conf line-by-line back in...
> 
> tl;dr   loader.conf problematic line and maybe an additional unknown in 
> either kernel text file.
> ___
> 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"


Half of loader.conf removed. (as below). Custom kernel restored and working.
# out snd_pcm_load="YES"
# out snd_acm_load="YES"
# out kern.msgbufsize="13"
# out kern.ipc.shmmni="1024"
# out kern.ipc.shmseg="1024"
# out hw.snd.maxautovchans="4"
# out hw.snd.targetirqrate="36"
# out hint.pcm.0.buffersize="65536" 
# out hw.snd.verbose="3"
# out kern.ipc.semmns="240"
# out kern.ipc.semume="40"
# out kern.ipc.semmnu="120"
# out vfs.read_max="128"
# out kern.randompid="1"
# out kern.ipc.shmmax="67108864" 
# out kern.ipc.shmall="32768"
# out vm.kmem_size="700M"
# out vm.kmem_size_max="700M"  
# out vfs.zfs.arc_max="250M"
# out kern.sched.preempt_thresh="224"
# out 

Re: [CFT] packaging the base system with pkg(8)

[Edward Tomasz Napierała]

On 0421T1526, Dan Partelly wrote:
> The scenario is:
> 
> Let’s say I have autofs_enable , working with media map.
> 
> If I have a CD in CD drive , all is well and when the system is fully booted 
> up
> /media contains a directory through which I can access the content of the 
> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens.
> /media does not contain a new access point for the new disk inserted in the 
> device.  
> 
> What I would expect is when I change the media in Cd-rom , a new 
> access point for the volume in question should be reated in /media.
> 
> Perhaps this functionality is exposed differently by the automounter,
> but them I would not expect the CDrom to be accessible at all though the 
> media map. 

If by "access point" you mean the directory, then it will, unless the CD
doesn't have a label - in that case the device name will be used instead,
and since it's the same device, it will be the same name - usually "cd0".

However - I've just checked to make sure and it works the way it should.
What you're decribing seems like you're missing the part of devd.conf(5)
responsible for notifying autofs about media change.  Do you?

> > he problem here is that it's quite hard to fix, there's a risk
> > of breaking existing functionality, and the problem is largely cosmetic.
> 
> until you have more than 10 of them there, when it largely annoying.
> anyway, what is the reason it is very hard to fix and it would break existing
> functionality. can you please shed some light ?  

Basically, the autofs doesn't support removing the nodes.  It wasn't
really required for the usual use case, and it simplified the code a lot.
Plan was to pick it up again with my next filesystem project, and simply
retrofit the changes back to autofs - but that hasn't happened (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: [CFT] packaging the base system with pkg(8)

[Dan Partelly]

Yes, you are right it misses the media change handler  in devd.conf. 
maybe it should bementioned somewhere in a man page if it is not
already there. Thanks for the pointer.

Anyway, if I would have written the system, what I would have done
is to consolidate both user mode daemons into one and make this
daemon a client of devd, fstyp a library, and handle all removable 
media inside transparent to the user, without requiring any modifications
 to devd.conf, and without relaying on shell scripts. 

Is there any reason you did not took this approach ? This is not
criticism, I am genuinely interested.

>  and simply
> retrofit the changes back to autofs - but that hasn't happened (yet).

Please consider doing it.  A kevent on /media would allow other programs
to see how volumes come and go, and I can imagine several situations 
where this can be handy. And too many directories left there do become
annoying. 

> On 21 Apr 2016, at 23:20, Edward Tomasz Napierała  wrote:
> 
> On 0421T1526, Dan Partelly wrote:
>> The scenario is:
>> 
>> Let’s say I have autofs_enable , working with media map.
>> 
>> If I have a CD in CD drive , all is well and when the system is fully booted 
>> up
>> /media contains a directory through which I can access the content of the 
>> CD-ROM. Now if you eject this CD , and insert a new one, nothing happens.
>> /media does not contain a new access point for the new disk inserted in the 
>> device.  
>> 
>> What I would expect is when I change the media in Cd-rom , a new 
>> access point for the volume in question should be reated in /media.
>> 
>> Perhaps this functionality is exposed differently by the automounter,
>> but them I would not expect the CDrom to be accessible at all though the 
>> media map. 
> 
> If by "access point" you mean the directory, then it will, unless the CD
> doesn't have a label - in that case the device name will be used instead,
> and since it's the same device, it will be the same name - usually "cd0".
> 
> However - I've just checked to make sure and it works the way it should.
> What you're decribing seems like you're missing the part of devd.conf(5)
> responsible for notifying autofs about media change.  Do you?
> 
>>> he problem here is that it's quite hard to fix, there's a risk
>>> of breaking existing functionality, and the problem is largely cosmetic.
>> 
>> until you have more than 10 of them there, when it largely annoying.
>> anyway, what is the reason it is very hard to fix and it would break existing
>> functionality. can you please shed some light ?  
> 
> Basically, the autofs doesn't support removing the nodes.  It wasn't
> really required for the usual use case, and it simplified the code a lot.
> Plan was to pick it up again with my next filesystem project, and simply
> retrofit the changes back to autofs - but that hasn't happened (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: extremely slow to get to loader

[Johannes Dieterich]

On Thu, Apr 21, 2016 at 12:16 PM, Allan Jude  wrote:
> On 2016-04-21 10:46, Johannes Dieterich wrote:
>> Dear all,
>>
>> with r298385, I observe extremely long times from turning on my laptop
>> to reach loader. This is a regression compared to a roughly 1 week old
>> CURRENT.
>>
>> This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup.
>>
>> Please let me know how I can help to solve this issue.
>>
>> Thanks,
>>
>> 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"
>>
>
> Can you describe where exactly it is slow?
Yes, it hangs after "BIOS drive C: is disk 0" for a good 3 minutes
before it eventually continues.

> Once you get to the loader menu (the beastie menu), can you choose the
> option to go to the loader prompt, and type:
> bcachestat
>
> And provide the output of that.
Here we go (w/o mistakes I hope...):
cache blocks: 32768
cache blocksz: 572
unit cache blocks: 32768
cached units: 1
1162 ops 0 bypasses 12109 hits 739 misses

Thanks so much for the response!

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"

[Bug 208938] usr.sbin/config does not preserve whitespace in static env

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: limits: setrlimit umtxp: Invalid argument

[Jeffrey Bouquet]

On Thu, 10 Mar 2016 07:16:05 +0900, Brendan Sechter  wrote:

> > Subject: Re: limits: setrlimit umtxp: Invalid argument
> > From: florian.ermi...@alumni.tu-berlin.de
> > Date: Wed, 9 Mar 2016 18:45:37 +0100
> > To: e...@vangyzen.net; sg...@hotmail.com; freebsd-current@freebsd.org
> >
> > Am 9. März 2016 16:59:47 MEZ, schrieb Eric van Gyzen :
> >> On 03/09/2016 09:49, Brendan Sechter wrote:
> >>> I am running an 11.0-CURRENT VM.
> >>> After recently updating, the following appears on startup and
> >>> dhclient fails to start.
> >>>
> >>> Starting dhclient.
> >>> limits: setrlimit umtxp: Invalid argument
> >>> /etc/rc.d/dhclient: WARNING: failed to start dhclient
> >>>
> >>> Similar messages appear for the following.
> >>>
> >>> devd pflog syslogd ntpd powerd sshd sendmail_submit
> >>> sendmail_msp_queue cron
> >>>
> >>> Reverting to the previous kernel did not resolve the issue.
> >>> I can manually start dhclient and ntp, but not sshd.
> >>>
> >>> I do not trust that my uname information is being updated with
> >>> with build, but here it is.
> >>>
> >>> $ uname -vm
> >>> FreeBSD 11.0-CURRENT #0 r287598: Thu Sep 10 14:45:48 JST 2015
> >>> root@:/usr/obj/usr/src/sys/MIRAGE_KERNEL amd64
> >>
> >> This information comes directly from the running kernel, so it looks
> >> like your kernel is not getting updated. This seems consistent
> >> with the above error messages, although I haven't tested this
> >> case. The userland tools are aware of the newly added umtxp
> >> limit, but the kernel is not aware.
> >>
> >> Eric
> >
> > I got this problem on my laptop, too. I somehow managed not to
> > install the kernel during a recent update so my userland is slightly
> > newer than my 11-CURRENT r292755 kernel (and also forgot to
> > make proper ZFS snapshots…).
> >
> > While I can build a newer kernel but when I boot i.e. r296556
> > `zfs(8)' coredumps and I can't mount anything but the rootfs…
> > I guess I need to get kernel & userland back in sync to fix this.
> >
> > I will try to build the userland matching my kernel first as
> > I know its revision from `uname -a`.
> > If anyone has a better approach or tips, please let me know.
> 
> My userland was up to date.  This is what I did to get the kernel
> in sync enough to resolve the issue.
> 
> svn up /usr/src # omit if want to use the exact same version as world
> cd /usr/src
> make buildkernel KERNCONF=MYKERNEL
> make installkernel KERNCONF=MYKERNEL
> 
> I found a problem with my kernel configuration in the process.
> The plan is to rebuild everything after the configuration issue is
> sorted out.  You may wish to use GENERIC just to get things up
> and running again.
> 
> Regards,
> -Brendan
> ___
> 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"


I've a working pf.ko kernel and nvidia.ko from r288246 Sep 26 2015 and an 
installed
buildworld from yesterday Apr 20 2016.  The kernel is custom and I've also a 
large-ish
loader.conf.  I've no wish to run GENERIC with either debugging symbols nor 
sound enabled.

sendmail_submit is broken, not a showstopper but root gets none of his mail.
cron is broken, not a showstopper but one cron I've setup does not run
Per this thread which narrowed down the issue of out of sync problems,
dhclient devd pflog syslogd ntpd and sshd  *if I had them used* would be
not functional.   Unsure in each case.

Given a 2004-ish custom kernel, a GENERIC from this month, and a GENERIC from 
Sept 2015, is there
any not time consuming way to do a diff between two or three of them and bring 
the custom
kernel upto par with the GENERIC as far as bootability, considering the 
possibility that it is
a loader.conf setting that is at fault?

something like /sbin/kernel-too-old
^^^

" please check foo foo from loader conf " or "please check bar bar from 
CUSTOM-K " or even
" foo bar from CUSTOM-K is missing... "  

...a utility that would lessen the need for adding/subtracting blocks
of  (custom ) kernel stuff to/from generic and recompiling one-by-one,
or vice-versa, to/from the custom kernel config,
 seems like a 40 day project UNLESS someone
has run into a similar custom -vs- generic situation as a matter of course and 
has a workflow to
lessen whatever time and compilation effort it takes, which is basically what I 
am asking here unless
a summer of code expert coder of FreeBSD fame knows that the hypothetical 
binary above could
be crafted more easily than not and be a tool for developers as well as simple 
FreeBSD users such
as myself...

Thanks
PS I encourage anyone with a readily helpful answer to add it to UPDATING as a 
resource for
persons other than myself who encounter the same difficulty...
___

Re: [CFT] packaging the base system with pkg(8)

[Dan Partelly]

The scenario is:

Let’s say I have autofs_enable , working with media map.

If I have a CD in CD drive , all is well and when the system is fully booted up
/media contains a directory through which I can access the content of the 
CD-ROM. Now if you eject this CD , and insert a new one, nothing happens.
/media does not contain a new access point for the new disk inserted in the 
device.  

What I would expect is when I change the media in Cd-rom , a new 
access point for the volume in question should be reated in /media.

Perhaps this functionality is exposed differently by the automounter,
but them I would not expect the CDrom to be accessible at all though the 
media map. 
 

> he problem here is that it's quite hard to fix, there's a risk
> of breaking existing functionality, and the problem is largely cosmetic.

until you have more than 10 of them there, when it largely annoying.
anyway, what is the reason it is very hard to fix and it would break existing
functionality. can you please shed some light ?  



> Huh, never heard about that.  I'd expect the existing mechanism to handle
> that case just fine.  Could you submit a PR?

> On 21 Apr 2016, at 12:57, Edward Tomasz Napierała  wrote:
> 
> On 0420T1545, dan_partelly wrote:
> 
> [..]
> 
>> Another example is the autofs mounter. The prject was marked as complete
>> by FreeBSD foundation in 2014. Last I tried it to autmount removable
>> devices, it left directory after directory in the autofs managed directory.
>> This is known behavior.
> 
> Yup.  The problem here is that it's quite hard to fix, there's a risk
> of breaking existing functionality, and the problem is largely cosmetic.
> 
>> It also did not worked as it should ??? (show it
>> manage removable media correctly ) changing CD/DVD media disks. Presumably
>> In could have somehow manage it to work by making yet another scaffolding
>> of scripts as a questionable glue between devd and automounters.  That if
>> devd receives media change notifications. I dont know. If not I could patch
>> the kernel, yeah. But it is just much to simple to not bother at all and
>> use OSx. 
> 
> Huh, never heard about that.  I'd expect the existing mechanism to handle
> that case just fine.  Could you submit a PR?
> 
> [..]
> 
> ___
> 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"

extremely slow to get to loader

[Johannes Dieterich]

Dear all,

with r298385, I observe extremely long times from turning on my laptop
to reach loader. This is a regression compared to a roughly 1 week old
CURRENT.

This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup.

Please let me know how I can help to solve this issue.

Thanks,

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"

some mtree missing in buildworld

[Julian H. Stacey]

Hi current@
There seems some invocation of mtree missing in make buildworld,
& also an undefined reference to `_libmd*
I detected it upgrading a year old current to today's current:

--
uname -a
FreeBSD blak.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #11881: Sun Mar 
22 19:23:17 CET 2015 
j...@blak.js.berklix.net:/usr/src/sys/amd64/compile/BLAK.small  amd64

rm -rf /usr/src 
mkdir /usr/src 
cd /usr/src
ctm -q  /pub/FreeBSD/development/CTM/src-cur/src-cur.12300xEmpty.gz
ctm -q /pub/FreeBSD/development/CTM/src-cur/src-*.1[0-9][0-9][0-9][0-9].gz
cat .ctm*
src-cur 12446   # That's todays latest
cat .svn_revision
298360

/etc/src.conf is an empty file ie all commented out

make obj

make buildworld
cc -O2 -pipe -DBERKLIX=YES -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 
-DTUI=1 -DDEBUGDIR=\"/usr/lib/debug\" -I. 
-I/usr/src/gnu/usr.bin/gdb/kgdb/../arch/amd64 
-I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd 
-I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/amd64 
-I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb 
-I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config 
-I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include 
-I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include 
-I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd 
-I/usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../../lib/libreadline/readline/.. -g 
-std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-loca!
 l-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter 
-Qunused-arguments  -o kgdb.full main.o kld.o kthr.o trgt.o trgt_amd64.o  
/usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../gdb/libgdb/libgdb.a 
/usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/libbfd.a 
/usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libopcodes/libopcodes.a  
/usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libiberty/libiberty.a  -lm 
-L/usr/obj/usr/src/gnu/lib/libreadline/readline 
-L/usr/obj/usr/src/gnu/lib/libreadline/readline -lreadline  -lncursesw  
-lncursesw  -lncursesw  -lgnuregex  -lkvm
main.o: In function `main':
/usr/src/gnu/usr.bin/gdb/kgdb/main.c:478: undefined reference to 
`kgdb_trgt_pc_fixup'
cc: error: linker command failed with exit code 1 (use -v to see 
invocation)
*** Error code 1

Stop.
make[6]: stopped in /usr/src/gnu/usr.bin/gdb/kgdb

make includes
Various breakages repaired by my subsequent manual mkdir eg
mkdir -p /usr/include/private/bsdstat

make includes
===> lib/libcasper/services (includes)
===> lib/libcasper/services/cap_dns (includes)
install  -C -o root -g wheel -m 444  
/usr/src/lib/libcasper/services/cap_dns/cap_dns.h /usr/include/casper/
install: /usr/include/casper/: No such file or directory
*** Error code 71

cd /usr/src/etc/mtree
make install
cd /etc/mtree 
vi -c/casper BSD.include.dist
cd /usr/src
make _worldtmp
cd /usr/obj/usr/src/tmp
tar cf - . | ( cd / && tar xf - )
ls -la /usr/include/casper
total 12
drwxr-xr-x   2 root  wheel   512 Apr 21 17:08 ./
drwxr-xr-x  60 root  wheel  6656 Apr 21 17:09 ../

cd /usr/src
make includes
cd /usr/src/gnu/usr.bin/gdb/kgdb ; make
Runs for a while
cd /usr/src/gnu/usr.bin/gdb/; make
Runs for a while
make upgrade_checks
make buildworld
cc -O2 -pipe -DBERKLIX=YES 
-I/usr/src/usr.bin/xinstall/../../contrib/mtree 
-I/usr/src/usr.bin/xinstall/../../lib/libnetbsd -g -std=gnu99 
-Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include  -static 
-L/usr/obj/usr/src/tmp/legacy/usr/lib -o xinstall.full xinstall.o getid.o   
-lmd -legacy
xinstall.o: In function `digest_init':
/usr/src/usr.bin/xinstall/xinstall.c:414: undefined reference to 
`_libmd_MD5Init'
...
/usr/src/usr.bin/xinstall/xinstall.c:470: undefined reference to 
`_libmd_SHA512_End'
cc: error: linker command failed with exit code 1 (use -v to see 
invocation)
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src/usr.bin/xinstall

cd /usr/src/lib/libmd ; make ; make install
cd /usr/src/usr.bin/xinstall  ; make ; make install
cd /usr/src; make buildworld

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich http://berklix.eu/jhs/
 Mail plain text,  No quoted-printable, HTML, base64, MS.doc.
 Prefix old lines '> '  Reply below old, like play script.  Break lines by 80.
 Let Brits in EU vote on Brexit https://petition.parliament.uk/petitions/112142
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail 

Re: OCZ ssdpx-1rvd0120 REVODRIVE support

[Markus Wild]

> > > HI! I've recently got a SSD device. Yes, not a disk, but a device.
> > > It's called, i. e. one of the first REVODRIVEs.
> > > It's a PCI-express card with two embedded ssd disks about ~ 55GB size.
> > > And it's a raid card. Fake software raid. You can set it up as a
> > > RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured
> > > or set it as JBOD or something else.
> > > You just won't be able to boot from this device in that case.

I used to have one of these in my workstation (mine was recognized as 4 SATA 
drives
of about 60GB). I had put these into a zfs pool with raidz1 and was able to 
boot from
the card without any issue. BIOS reported them as 4 individual drives. These 
are 
pre-NVME, so no NVME driver was necessary. Unfortunately, the card recently 
died of
old age, so I can't provide any more than historic references. The type was 
OCZSSDPX-1RVDX0240 . 

Cheers,
Markus
___
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: [CFT] packaging the base system with pkg(8)

[Edward Tomasz Napierała]

On 0420T1545, dan_partelly wrote:

[..]

> Another example is the autofs mounter. The prject was marked as complete
> by FreeBSD foundation in 2014. Last I tried it to autmount removable
> devices, it left directory after directory in the autofs managed directory.
> This is known behavior.

Yup.  The problem here is that it's quite hard to fix, there's a risk
of breaking existing functionality, and the problem is largely cosmetic.

> It also did not worked as it should ??? (show it
> manage removable media correctly ) changing CD/DVD media disks. Presumably
> In could have somehow manage it to work by making yet another scaffolding
> of scripts as a questionable glue between devd and automounters.  That if
> devd receives media change notifications. I dont know. If not I could patch
> the kernel, yeah. But it is just much to simple to not bother at all and
> use OSx. 

Huh, never heard about that.  I'd expect the existing mechanism to handle
that case just fine.  Could you submit a PR?

[..]

___
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"