Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

[Bakul Shah]

$ git bisect good
b377ff8110e3489eb6e6b920b51a2384dfc4eb0b is the first bad commit

> On Feb 9, 2024, at 8:13 PM, Mark Millard  wrote:
> 
> Summary:
> 
> pcib0:  mem 0x7d50-0x7d50930f 
> irq 80,81 on simplebus2
> pcib0: parsing FDT for ECAM0:
> pcib0:  PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000
> . .
> rman_manage_region:  request: start 0x6, end 
> 0x6000f
> panic: Failed to add resource to rman
> 
> 
> Detail:
> 
> 
> . .
> pcib0:  mem 0x7d50-0x7d50930f 
> irq 80,81 on simplebus2
> pcib0: parsing FDT for ECAM0:
> pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: PCI addr: 0x0, CPU addr: 0x0, Size: 0x0
> pcib0: Bus is not cache-coherent
> rman_reserve_resource_bound:  request: [0xfd50, 
> 0xfd50930f], length 0x9310, flags 100, device pcib0
> rman_reserve_resource_bound: trying 0x1fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x1fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x31bf <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x33296fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x39bf1fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x39c02fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x39c06fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x39c07fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x39c08fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x39c2afff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x39c36fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x39c37fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x3b03 <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x3b04 <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x3b2f <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x3ee61fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x3ee63fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0x3fff <0xfd50,0x930f>
> rman_reserve_resource_bound: tried 0xfbff <0xfd50,0x930f>
> considering [0xfc00, 0xfd5d1fff]
> truncated region: [0xfd50, 0xfd50930f]; size 0x9310 (requested 0x9310)
> candidate region: [0xfd50, 0xfd50930f], size 0x9310
> splitting region in three parts: [0xfc00, 0xfd4f]; [0xfd50, 
> 0xfd50930f]; [0xfd509310, 0xfd5d1fff]
> rman_manage_region:  request: start 0xc000, end 0x
> pcib0: hardware identifies as revision 0x304.
> pcib0: note: reported link speed is 5.0 GT/s.
> rman_reserve_resource_bound:  request: [0x51, 0x51], length 0x1, 
> flags 0, device pcib0
> rman_reserve_resource_bound: trying 0 <0x51,0>
> rman_reserve_resource_bound: tried 0 <0x51,0>
> rman_reserve_resource_bound: tried 0x1 <0x51,0>
> rman_reserve_resource_bound: tried 0x2 <0x51,0>
> rman_reserve_resource_bound: tried 0x3 <0x51,0>
> rman_reserve_resource_bound: tried 0x4 <0x51,0>
> rman_reserve_resource_bound: tried 0x5 <0x51,0>
> rman_reserve_resource_bound: tried 0x6 <0x51,0>
> rman_reserve_resource_bound: tried 0x7 <0x51,0>
> rman_reserve_resource_bound: tried 0xc <0x51,0>
> rman_reserve_resource_bound: tried 0xd <0x51,0>
> rman_reserve_resource_bound: tried 0xe <0x51,0>
> rman_reserve_resource_bound: tried 0xf <0x51,0>
> rman_reserve_resource_bound: tried 0x10 <0x51,0>
> rman_reserve_resource_bound: tried 0x11 <0x51,0>
> rman_reserve_resource_bound: tried 0x12 <0x51,0>
> rman_reserve_resource_bound: tried 0x17 <0x51,0>
> rman_reserve_resource_bound: tried 0x18 <0x51,0>
> rman_reserve_resource_bound: tried 0x1a <0x51,0>
> rman_reserve_resource_bound: tried 0x1b <0x51,0>
> rman_reserve_resource_bound: tried 0x22 <0x51,0>
> rman_reserve_resource_bound: tried 0x23 <0x51,0>
> rman_reserve_resource_bound: tried 0x24 <0x51,0>
> rman_reserve_resource_bound: tried 0x25 <0x51,0>
> rman_reserve_resource_bound: tried 0x26 <0x51,0>
> rman_reserve_resource_bound: tried 0x27 <0x51,0>
> rman_reserve_resource_bound: tried 0x28 <0x51,0>
> rman_reserve_resource_bound: tried 0x29 <0x51,0>
> rman_reserve_resource_bound: tried 0x4e <0x51,0>
> rman_reserve_resource_bound: tried 0x4f <0x51,0>
> considering [0x50, 0x]
> truncated region: [0x51, 0x51]; size 0x1 (requested 0x1)
> candidate region: [0x51, 0x51], size 0x1
> 

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Bakul Shah]

On Jan 25, 2024, at 8:15 AM, Warner Losh  wrote:
> 
> What can fdisk and/or disklabel repair that gpart can't?

May be add a section in gpart that shows how to map fdisk &
bsdlabel functionality to gpart? Better still, why not
provide scripts for fdisk/bsdlabel that use gpart underneath?
FreeBSD should strive to provide backward compatibility

Re: git repo port issues?

[Bakul Shah]

On Jan 3, 2024, at 11:22 AM, Brooks Davis  wrote:
> 
> Nothing about dates is centralized in git, but some server side checks
> could be implemented on CommitDate.  IMO we should require that
> CommitDate be >= the previous one and less than "now".

Given that git commit objects form a DAG, I don't see how you can
impose linearity.

Re: nvme timeout issues with hardware and bhyve vm's

[Bakul Shah]

Thanks.

It may be worth checking the temp periodically and warning the user in case it 
is too high (70ºC+ or something). Even for devices that allow internal 
throttling, a user might wish to know whether the device neads a (better) 
heatsink.

> On Dec 7, 2023, at 5:02 PM, Maxim Sobolev  wrote:
> 
> How quickly it heats up depends on lots of factors. Usually those devices 
> burn some 3-7 watts per stick at 100% load, so maybe this would give you some 
> idea. At least some of them support several toggleable performance modes, 
> which use throttling internally to limit power consumption to a certain level 
> (man nvmecontril). It helped me recently to make a system stable, which 
> otherwise would hang with timeout after reaching 70-75C until I got the 
> chance to take it apart and attach a heatsinks to the nvmes. Once the 
> temperature dropped to <= 50C the drives become 100% stable.
> 
> -Max
> 
> On Thu, Dec 7, 2023, 4:07 PM Bakul Shah  <mailto:ba...@iitbombay.org>> wrote:
>> On Dec 7, 2023, at 3:59 PM, Warner Losh > <mailto:i...@bsdimp.com>> wrote:
>> > 
>> > 
>> >  *Overheating caused hang of NVMe controller or PCI bridge on SSD, or
>> > 
>> > Yes. Most drive's firmware when it overheats resets. There might be 
>> > something
>> > that the pci code can do when this happens to retrain the link, reprogram 
>> > the
>> > config registers, etc.
>> 
>> How quickly can the device heat up? Can it be queried frequently
>> enough act before it overheats by throttling io?
>> 
>> 
>> 
>> 

Re: nvme timeout issues with hardware and bhyve vm's

[Bakul Shah]

On Dec 7, 2023, at 3:59 PM, Warner Losh  wrote:
> 
> 
>  *Overheating caused hang of NVMe controller or PCI bridge on SSD, or
> 
> Yes. Most drive's firmware when it overheats resets. There might be something
> that the pci code can do when this happens to retrain the link, reprogram the
> config registers, etc.

How quickly can the device heat up? Can it be queried frequently
enough act before it overheats by throttling io?

installkernel with PORTS_MODULES+=graphics/drm-515-kmod stopped working

[Bakul Shah]

I build{world,kernel} on one machine but install
everything from the target machine, with /usr/obj
and /usr/src from the build machine nfs mounted.
/etc/src.conf (on target and build machines) has
PORTS_MODULES+=graphics/drm-515-kmod to build
this port at the same time. This used to work at
least until Nov 1, 2023 but now stopped working.

What I don't understand is why is install trying
to install to /usr/obj/..., which is really on
the build tree.

It this known? Is this style of building .ko ports
still supported?

The make infrastructure has gotten far too complicated
and baroque over the years so before diving into it
I am looking any shortcuts! Thanks!

[note: /usr/ports is mounted from the build machine
/usr/src is symlinked to /home/FreeBSD/stable-14
/etc/src.conf is the same on both machines.
From target (as root) I can create root owned files
under /usr/obj on the target]

===>   drm-515-kmod not installed, skipping
===>  Staging for drm-515-kmod-5.15.118_2
No name and/or group mapping for uid,gid:(0,0)
No name and/or group mapping for uid,gid:(0,0)
...
No name and/or group mapping for uid,gid:(0,0)
===>   Generating temporary packing list
===> dmabuf (install)
install -T release -o root -g wheel -m 555   dmabuf.ko 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/stage/boot/modules/
===> ttm (install)
install -T release -o root -g wheel -m 555   ttm.ko 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/stage/boot/modules/
===> drm (install)
install -T release -o root -g wheel -m 555   drm.ko 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/stage/boot/modules/
No name and/or group mapping for uid,gid:(0,0)
install: 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/stage/boot/modules/drm.ko:
 chown/chgrp: Operation not permitted
*** Error code 71

Stop.
make[6]: stopped in 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/drm-kmod-drm_v5.15.118_3/drm
*** Error code 1

Stop.
make[5]: stopped in 
/usr/obj/home/FreeBSD/stable-14/amd64.amd64/sys/GENERIC/usr/ports/graphics/drm-515-kmod/work/drm-kmod-drm_v5.15.118_3
*** Error code 1

Re: bhyve -G

[Bakul Shah]

> On Nov 15, 2023, at 7:57 AM, John Baldwin  wrote:
> 
> On 10/9/23 5:21 PM, Bakul Shah wrote:
>> Any hints on how to use bhyve's -G  option to debug a VM
>> kernel? I can connect to it from gdb with "target remote :"
>> & bhyve stops the VM initially but beyond that I am not sure.
>> Ideally this should work just like an in-circuit-emulator, not
>> requiring anything special in the VM or kernel itself.
> 
> step only works on Intel CPUs currently (and is a bit fragile
> anyway due to interrupts firing while you try to step, but that
> happens for me in QEMU as well).   Breakpoints should work fine.
> I tend to use 'until' to do stepping (basically stepping via
> temporary breakpoints) when debugging the kernel this way.

Thanks for your response!

I can ^C to stop the VM, examine the stack, set breakpoints,
continue etc. but when the breakpoint is hit, kgdb doesn't
regain control -- instead I get the usual

db> ...

prompt on the console. I guess I have to set some sysctl for
this?

Thanks,
Bakul

bhyve -G

[Bakul Shah]

Any hints on how to use bhyve's -G  option to debug a VM
kernel? I can connect to it from gdb with "target remote :"
& bhyve stops the VM initially but beyond that I am not sure. 
Ideally this should work just like an in-circuit-emulator, not
requiring anything special in the VM or kernel itself.

Thanks!

Re: Continually count the number of open files

[Bakul Shah]

On Sep 12, 2023, at 11:59 PM, Graham Perrin  wrote:
> 
> (I'm a tcsh user, I can easily 'sh' before running the command.)

You can switch to zsh. Most of csh/tcsh + sh + many more features.

> baloo is not used in 273669.

It certainly feels like an inotify like use or a file-descr leak.
The bug reporter can try "procstat fd " on running processes
to see which one has all those open files. Another thing worth
trying is to run under ktrace -di to see which syscalls were made.

Re: Continually count the number of open files

[Bakul Shah]

On Sep 11, 2023, at 11:38 PM, Graham Perrin  wrote:
> 
> Can anything like systat(1) present a count, continually?

How about 

while sleep 0.1; do sysctl -n kern.openfiles; done

Or you can write a small program using sysctl(3).

> 
> I'd like to monitor, after log in to Plasma (X11), in connection with 
> .

Not sure checking how many files are open will help you.
Looks like "baloo" is using inotify to watch changes on
every file & directory or something. Simulating inotify
with kqueue under FreeBSD doesn't scale well. FreeBSD
should add inotify.

Re: src.conf(5) to specify multiple flavours of a port

[Bakul Shah]

On Aug 21, 2023, at 9:24 PM, Graham Perrin  wrote:
> 
> In a thread elsewhere, as an example that did not involve src.conf, Mark 
> Johnston wrote: 
> 
>> $ cd /usr/ports/graphics/gpu-firmware-intel-kmod
>> $ sudo make reinstall FLAVOR=kabylake
> 
> How might I use /etc/src.conf to achieve much the same, with a different port?

Since /etc/src.conf is included from make, may be you can use some make feature
for conditional define? 

Re: native recording of all network connections on freebsd

[Bakul Shah]

On Dec 28, 2022, at 6:21 AM, Dan Mack  wrote:
> 
> I'm wondering if anyone can help point me at a good way to continously 
> capture every inbound and outbound connection made to a freebsd system. I'd 
> prefer a way that is native in base if possible.   I don't really want to 
> record all the packets, just the src:dest:rport:dport stats.

I'd build a simple program using pcap(3), and compile a bpf program
using pcap_compile and then do pcap_setfilter to capture just the
packets I want. Then save the desired fields from captured packets
(and use a hashtable if just {src,dst}{ip,port} are wanted). There
are online examples one can start from.

Re: recover deleted file

[Bakul Shah]

This may help? I’ve no experience with it, I just googled it for you. The 
comp.sources.misc usenet group in volume 17 issue 23 (in 1991) has an undelete 
program that supposedly works with 4.3BSD — probably won’t work with FreeBSD’s 
version but if you’re desperate it could be a starting point.
https://www.ufsexplorer.com/solutions/recover-deleted-files-bsd.php

Since you asked for advice, this may just be the nature’s way of telling you 
you really didn’t need the file. It can be a very “free”ing experience :-)

> On Apr 16, 2022, at 8:03 AM, Sami Halabi  wrote:
> 
> 
> okay...
> all seems very time consuming operations!!
> 
> There should be an os "undelete" as happens in NTFS for example.. which is 
> very fast and can be done also with extra tools without a hassle.
> 
> for now I got backup from last day .. caused me a lot of troubles, not say 
> legal ones, but I passed the point to hold the machine down.
> 
> any advice?
> 
> Maybe UFS developer would do a rework so latest deleted inodes would put in a 
> "recycle bin" (maybe with a sysctl or whatever) for say one day (or any other 
> configurable sysctl) and allow to recover quickly or "force delete / empty 
> recycle bin" , rather than delete and give back space immediately for use and 
> destroy possibility to restore.
> 
> my 2 cents.
> 
> Sami
> 
> 
> 
>> On Sat, Apr 16, 2022 at 5:23 PM Julian H. Stacey  wrote:
>> > Then I would reboot single user, 
>> > fsck & mount only the partitions the data was Not on.,
>> > dd the partition to recover,
>> > then fsck the partition & mount it, & go multi user,
>> > then I'd make a 2nd copy of the partition with data to recover
>> 
>> Oops. I meant:
>> 
>> .. I'd make a 2nd copy (with cp) from the 1st image file,
>>not of course Not a copy of raw decice partition after fsck
>>has discarded blocks.
>> 
>> The spare 2nd. copy because I've zapped data too often, trying to rescue
>> it, while fumbling with unfamiliar resue tools: its easier to
>> have a play image one can experimentaly try to recover from, &
>> periodicaly while one learns, & that gets in a mess,  one can refresh
>> copy from master to experimental copy.
>> 
>> If any recovery tools want to run on devices, & refuse images in files, use
>> mdconfig -a -t vnode -f imagefile
>> 
>> I recall FS has journals etc, 
>> Specalists on list fs@
>> 
>> Cheers,
>> -- 
>> Julian Stacey  http://berklix.com/jhs/ http://StolenVotes.UK  
>> Kill / remove Putin to stop him killing & provoking world war.
> 
> 
> -- 
> Sami Halabi
> Information Systems Engineer
> NMS Projects Expert, FreeBSD SysAdmin Expert
> Asterisk Expert

Re: 14-CURRENT: www/nextcloud: php occ/web access : Segmentation fault

[Bakul Shah]

On Jun 28, 2021, at 1:39 PM, O. Hartmann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> 
> Hello,
> 
> we ran into serious trouble here with an www/nextcloud installation on a 
> recent 14-CURRENT
> (FreeBSD 14.0-CURRENT #23 main-n247612-e6dd0e2e8d4: Mon Jun 28 18:08:20 CEST 
> 2021 amd64).
> Ports tree is up to date and ports are built via traditional "make". Port 
> www/nextcloud, all
> mod_ ports and even every php-* port (php74 is installed and default) has 
> been recompiled
> within the last two weeks via "portmaster -f".
> 
> The phenomenon occured back a couple of weeks, when access from the web via 
> cjromoum and/or
> firefox reported out of the sudden "Secure Connection Failed". I checked the 
> Apache
> 2.4 server's certificate (self signed,never had been an issue so far), but 
> there seems no
> issue to exist.
> It got very strange when I tried to perfom an upgrade and/or check via
> 
> cd /usr/local/www/nextcloud
> su -m -c "/usr/local/bin/php ./occ upgrade"
> 
> Whenever I access occ, I receive an @"Segmentation fault".
> The I checked the server's error log and I found for each access of the 
> nextcloud instance an
> entry like
> 
> [Tue Jun 01 06:04:40.667026 2021] [core:notice] [pid 81123:tid 34374492160] 
> AH00052: child pid
> 24598 exit signal Segmentation fault (11)
> 
> Well, I'm out of ideas, it seems nextcloud, php or apache ar all in 
> combination do have a
> serious problem hard to come by with 14-CURRENT (another instance running on 
> 12.2-RELENG
> doesn't have any issues).
> 
> Can someone hint me to what to do track this nasty error?

Some general ideas:

You can use ktrace and tcpdump to capture in some detail what is going on.
ktrace can tell you if there was a failing open near the crash (often due to
the "all the world is linux" syndrome). There should be a core dump connected
to the segfault - make sure coredumpsize limit is not set to 0. You may be
able to get a stacktrace from it. You can then compile the offending program
with -g and capture file:line with gdb. You can then pore over the source
code and add some checks or traps of your own (if you are guessing what the
bug may be). Also look at /var/log/messages for anything unusual. ["Unusual"
may become more apparent as you gain debugging experience.]

If you have a bug report, adding such relevant details may be of help to others.

Note that if you switch to a different version of *some* s/w piece, the
problem may disappear. That may be fine if you are under time pressure and
just want to work around the problem but in general it is better to try to
catch the bug without changing its environment.

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 19, 2021, at 4:19 PM, Thomas Laus  wrote:
> 
> On 6/19/21 2:21 PM, Bakul Shah wrote:
>> 
>> You may wish to see if Andriy Gapon's method (LOCAL_MODULES_DIR, 
>> LOCAL_MODULES)
>> works better for you.
>> 
>> I trust Makefile* to do the right thing with META_MODE and CCACHE (and if 
>> they
>> don't, it is a bug that would need to be fixed) so I personally don't see the
>> need to "rm -rf /usr/obj/*".
>> 
> I have been performing the rm -rf /usr/obj/* procedure almost weekly
> since FreeBSD 4.1 and has kept me out of trouble for many years.  The PC
> that I use to update Current can build both world and kernel in under an
> hour with a clean object directory.  Performing a 'git up ports' and
> rebuilding the drm module before building world is not a major time
> consumer for me if I remember to do it first.

One final response in this thread!

# cd /usr/src; git pull
Already up to date.
# make -j8 buildworld buildkernel >& err
# grep 'built in' err
>>> World built in 132 seconds, ncpu: 4, make -j8
>>> Kernel(s)  GENERIC built in 459 seconds, ncpu: 4, make -j8
# reboot
...
# uname -v
FreeBSD 14.0-CURRENT #6 main-n247581-0bcd49c13ada: Fri Jun 25 14:45:59 PDT 2021
...

This includes drm-kmod. I had run the same 4 days back. 

This is on a bhyve *virtual machine* (4 cores, 8GB RAM).
Its "disk" is a zfs file (pretending to be NVME) on a
3 year old ryzen box with 8 cores and 64GB RAM. The host
is running 13.0-RELEASE-p1.

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 18, 2021, at 7:05 AM, Thomas Laus  wrote:
> 
> On 6/10/21 11:13 AM, Bakul Shah wrote:
>> This is what I did:
>> 
>> git clone https://github.com/freebsd/drm-kmod
>> ln -s $PWD/drm-kmod /usr/local/sys/modules
>> 
>> Now it gets compiled every time you do make buildkernel.
>> If things break you can do a git pull in the drm-kmod dir
>> and rebuild.
>> 
> That did not work for me.  The buildkernel operation failed at the
> operation 'cleandir' phase.  The message was 'don't know how to make
> cleandir stop'.

I suspect you are not using WITH_META_MODE=yes. That seems to obviate
the need for running cleandir though I don't how (and I don't have the
patience to wade through the complex logic in /usr/src/Makefile*).
FWIW, my build flags:

$ cat /etc/{make,src,src-env}.conf
MALLOC_PRODUCTION=yes
WITHOUT_CLANG=yes
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/usr/obj/ccache
WITH_META_MODE=yes

If you forget to "kldload filemon" make build{kernel,world} will
remind you!

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 15, 2021, at 9:03 AM, John Baldwin  wrote:
> 
> On 6/10/21 8:13 AM, Bakul Shah wrote:
>> On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:
>>> The drm-kmod module is the latest from the pkg server.  It all
>>> worked this past Monday after the recent drm-kmod update.
>> This is what I did:
>> git clone https://github.com/freebsd/drm-kmod
>> ln -s $PWD/drm-kmod /usr/local/sys/modules
>> Now it gets compiled every time you do make buildkernel.
>> If things break you can do a git pull in the drm-kmod dir
>> and rebuild.
> 
> This is what I do now as well.  I think this is probably the
> sanest approach to use on HEAD at least.

IIRC I learned this from one of your posts.

The PORTS_MODULES approach results in installing kernel modules
/boot/modules, which doesn't track /boot/kernel*/.

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 10, 2021, at 9:49 AM, Philipp Ost  wrote:
> 
> On 6/10/21 5:13 PM, Bakul Shah wrote:
>> On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:
>>> The drm-kmod module is the latest from the pkg server.  It all
>>> worked this past Monday after the recent drm-kmod update.
>> This is what I did:
>> git clone https://github.com/freebsd/drm-kmod
>> ln -s $PWD/drm-kmod /usr/local/sys/modules
>> Now it gets compiled every time you do make buildkernel.
> 
> Why don't you set PORTS_MODULES in make.conf accordingly?

I used to do that but ran into problems such as doing
pkg upgrade which wanted to overwrite it when the port was
updated.

Re: drm-kmod kernel crash fatal trap 12

[Bakul Shah]

On Jun 10, 2021, at 7:13 AM, Thomas Laus  wrote:
> The drm-kmod module is the latest from the pkg server.  It all
> worked this past Monday after the recent drm-kmod update.

This is what I did:

git clone https://github.com/freebsd/drm-kmod
ln -s $PWD/drm-kmod /usr/local/sys/modules

Now it gets compiled every time you do make buildkernel.
If things break you can do a git pull in the drm-kmod dir
and rebuild.

Re: URL for stable/13

[Bakul Shah]

> On Mar 2, 2021, at 8:18 AM, bob prohaska  wrote:
> 
> A while back I obtained a buildable source tree for stable/13 
> but it hasn't been updated in the last few days. Running
> git remote show origin 
> reports in part
> 
> Fetch URL: https://git.FreeBSD.org/src.git
> Push  URL: https://git.FreeBSD.org/src.git
> HEAD branch: main
> Remote branches:
>   main tracked
> 
> .
> 
> Local branch configured for 'git pull':
>   stable/13 merges with remote stable/13
> Local ref configured for 'git push':
>   stable/13 pushes to stable/13 (local out of date)
> 
> Thanks for reading, any hints how to get back in sync apprecidated. 
> This is used for self-hosting on a Raspberry Pi, if it matters.  

Compare your local "git log" with
https://github.com/freebsd/freebsd-src/commits/stable/13

It may seem out of date as older commits are cherry picked into this branch.
For example the latest commit shows a date of Feb 20. On my local git:

$ git branch | grep '\*'
* stable/13
$ git log -n 1
Author: Kristof Provost 
Date:   Sat Feb 20 10:13:33 2021 +0100

   bridge tests: Test STP on top of VLAN devices

   This is basically the same test as the existing STP test, but now on top
   of VLAN interfaces instead of directly using the epair devices.

   MFC after:  1 week
   Sponsored by:   Orange Business Services
   Differential Revision:  https://reviews.freebsd.org/D28861

   (cherry picked from commit 26492ba2716f8b839f743bb663ce47405990fdf0)

___
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: no graphics on a Dell Vostro 131

[Bakul Shah]

On Feb 22, 2021, at 6:29 PM, Lizbeth Mutterhunt, Ph.D 
 wrote:
> 
> so, it's my great-grandma and has since recent update of the glib package
> the following problem when trying to start the DE or even lightdm, sddm,
> cdm... the reference output of X is:
> 
> ld-elf.so.1: /usr/local/lib/libglib-2.0.so0: Undefined symbol
> "eventfd@FBSD1_6"
> 
> what I did so far:
> 
> a) make kernel and userspace
> b) trying to compile devel/glib20 with an error something like cant't find
> textbook.xsl to be downloaded although there.
> c) trying to rebuild the linker, errors on compile: the above error
> message.
> 
> When trying to add hald to /etc/rc.conf I get the same error message! Is
> the linker dead or is it the new version 2.66.7_1 of glib?
> 
> what to do now?
> slim works but doesn't start any session (Plasma, GNOME, XFCE4). Starting
> plasma manually: same error.
> 
> Any help appreciated,
> 
> Lizbeth

There is no eventfd.c in /usr/src/lib/libc/gen in -12.x. It was
added on Dec 23, 2020 and seems to be in -13 and later.

If you are running -12.x, you may wish to either make sure you are 
installing packages from a -12 repo or update your OS to 13.0-BETA3.


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

Warm boot of the axge USB device fails

[Bakul Shah]

This is on a 13.0-STABLE system but this was also a problem while 13.0 was 
-current.

If I warmboot (reboot) the system the axge USB GbE driver fails:

# dmesg|grep axge
Feb 19 15:03:00 motile kernel: axge0 on uhub1
Feb 19 15:03:00 motile kernel: axge0:  on usbus0
Feb 19 15:03:00 motile kernel: axge0: attaching PHYs failed


If coldboot the system the device connects fine:

# dmesg|grep axge
Feb 19 16:03:42 motile kernel: axge0 on uhub1
Feb 19 16:03:42 motile kernel: axge0:  on usbus0
Feb 19 16:03:42 motile kernel: miibus2:  on axge0
Feb 19 16:03:42 motile kernel: ue1:  on axge0

Interesting that the second line in each case is different. Is there a 
workaround for this?

Thanks!
___
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: upgrade stable/12 -> stable/13 zfs + boot partition Mediasize 64K

[Bakul Shah]

On Feb 12, 2021, at 4:01 PM, Russell L. Carter  wrote:
> 
> This reminds me of a question that I had, does a stable/13
> installworld install the bootcode?  I am now guessing it
> doesn't, on account of it might be difficult to figure
> out what partition to install it to.

There are just too many booting variations for it to know what
is the right thing to do. And even if it could figure this out,
the boot partition may be too small :-)
___
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: upgrade stable/12 -> stable/13 zfs + boot partition Mediasize 64K

[Bakul Shah]

On Feb 11, 2021, at 7:13 PM, Russell L. Carter  wrote:
> 
> root@terpsichore> gpart show
> =>   34  625142381  da0  GPT  (298G)
> 341281  freebsd-boot  (64K)
>16283886082  freebsd-swap  (4.0G)
>8388770  6167536453  freebsd-zfs  (294G)

You can do something like

gpart delete -i 2 da0
gpart resize -s 512k -i 1 da0
gpart add -t freebsd-swap da0
gpart bootcode -p /boot/gptzfsboot -i 1 da0

gpart list da0
will show the swap partition last but it will still be /dev/da0p2

Practice on a md0 device if you want to test this.

truncate -s 20G file
mdconfig -a -t vnode -f file
gpart create -s GPT md0
etc.
___
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: DRM and higher screen resolutions on older hardware for current/13-ALPHA3

[Bakul Shah]

> On Feb 5, 2021, at 6:09 AM, George Michaelson  wrote:
> 
> I have a Lenovo Edge 420 with the ATI/Radeon graphics card.
> 
> The "this .ko, that blob" thing is really confusing if you've been out
> of the loop for a while, and with older hardwar (its 8+ year old
> laptop) its not impossible its fallen off the curve of available .ko
> drivers.
> 
> Anyone have any practical guidance to which radeon.ko I want to load?
> Not seeing valid Xorg with any of them and finding 640x480 tiresome.

In rc.conf I have

kld_list="ig4 iichid amdgpu"

Replace amdgpu with radeonkms. It will in turn load various
radeon*_bin.ko modules for firmware. I don't have this
card so this is just a guess (I am running 13.0-ALPHA3).
Compile /usr/ports/graphics/drm-fbsd13-kmod at the same
time as the kernel by adding

PORTS_MODULES=graphics/drm-fbsd13-kmod
PORTS_MODULES+=graphics/gpu-firmware-kmod

to /etc/src.conf. AFAIK installing a package won't work.

I need ig4 and iichid drivers for the touchpad.
___
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: Updating current i386 broke wlan0...

[Bakul Shah]

On Dec 11, 2020, at 1:55 PM, Chris  wrote:
> 
> Well FWIW when I've been confronted with the need to perform an "unorthodox" 
> upgrade
> path. I always perform a
> cd / && cp -rp /etc /eetc
> *prior* to a mergemaster(8)
> because you never know. ;-)

Just commit every *working* set of files in /etc & /usr/local/etc
to git or something :-) 

___
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: KLD zfs.ko: depends on kernel - not available or version mismatch

[Bakul Shah]

On Dec 8, 2020, at 10:10 AM, Alban Hertroys  wrote:
> 
> So I tried again to move to HEAD:
> 
>   cd /usr/src
>   svn up
>   make buildworld -j12
>   make buildkernel -j12
>   make installkernel
>   shutdown -r now
>   
>   mount -u /
>   zpool import -Nf system (my /usr FS)
> 
> KLD zfs.ko: depends on kernel - not available or version mismatch
> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> 

cd /usr/obj/usr/src/amd64.amd64/sys/GENERIC
ls -l kernel /boot/kernel/kernel
ls -l modules/usr/src/sys/modules/zfs/zfs.ko /boot/kernel/zfs.ko
cmp modules/usr/src/sys/modules/zfs/zfs.ko /boot/kernel/zfs.ko

The kernel should be *older* than zfs.ko and both instances of zfs.ko
should be identical.

One other thought is to manually do

kldload opensolaris.ko zfs.ko

In single user mode before using zpool. I have

opensolaris_load="YES"
zfs_load="YES"

in /boot/loader.conf but you may not want to add those until you know
zfs works.
___
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: panic shortly after boot when amdgpu.ko is loaded (fpu?)

[Bakul Shah]

> On Nov 27, 2020, at 1:47 PM, Bakul Shah  wrote:
> 
> 
> 
>> On Nov 27, 2020, at 9:09 AM, Rebecca Cran  wrote:
>> 
>> On 11/27/20 4:29 AM, Hans Petter Selasky wrote:
>>> 
>>> Is the problem always triggered by hald? If you disable hald in rc.conf, 
>>> does the system run for a longer period of time?
>> 
>> It turns out that disabling ntpd let the system run for a longer period of 
>> time - until I ran "sysctl sys" at which point I got a panic.
>> 
>> And this time the panic actually implicates amdgpu.ko, which is an 
>> improvement:
>> 
>> 
>> #9  0x in ?? ()
>> #10 0x82a14c4e in amdgpu_device_get_pcie_replay_count ()
>>   from /boot/modules/amdgpu.ko
>> #11 0x82a14b80 in sysctl_handle_attr () from /boot/modules/amdgpu.ko
>> 
>> #12 0x80c06cc1 in sysctl_root_handler_locked (oid=0xfe02133ff000,
>>arg1=0xfe016e360980, arg2=-8724518803888, req=0xfe016e360980,
>>tracker=0xf81099af6280) at /usr/src/sys/kern/kern_sysctl.c:184
>> #13 0x80c0610c in sysctl_root (oidp=,
>>arg1=0xf810aa27e650, arg2=-2100190360, req=0xfe016e360980)
>>at /usr/src/sys/kern/kern_sysctl.c:2211
>> 
>> 
>> Since it _is_ a problem in amdgpu, I'll stop this thread and re-post on 
>> freebsd-x11.
> 
> FWIW, I am using amdgpu on a Ryzen 5 3500U system on a couple days old
> -current (r368025). "sysctl sys" complains about "unknown oid 'sys'".
> I am runing hald & ntpd.  I had a few amdgpu related panics initially
> but they vanished once I added
>   PORTS_MODULES=graphics/drm-devel-kmod
> to /etc/src.conf to compile it along with the kernel. I am running
> GENERIC-NODEBUG. The machine gets rebooted when I install a new kernel
> (usually once a week).
> 
> My guess is some weird interaction rather than something in amdgpu.

To get sysctl sys working I compiled a GENERIC kernel from today's
368108 revision and so far there are no problems.

$ sysctl sys.device.drmn0.pcie_replay_count
sys.device.drmn0.pcie_replay_count: 0

sysctl -a also works.

Last commit log on drm-devel-kmod (the last tiem may be what you're
running into):
Author: manu 
Date:   Mon Nov 9 13:37:12 2020 +

drm-current-kmod/drm-devel-kmod: Update to latest version

- Use acpi code from base (thanks to wulf@)
- Add radeon/i386 patches (thanks to tilj@)
- Translate O_ flags for linuxulator (thanks to Greg V)
- Lot of linuxkpi cleanup
- Hack for amdgpu when the IP isn't init properly, this happens
  on one of my laptop with a dGPU. We still don't support it but
  we don't panic when we load amdgpu


___
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: panic shortly after boot when amdgpu.ko is loaded (fpu?)

[Bakul Shah]

> On Nov 27, 2020, at 9:09 AM, Rebecca Cran  wrote:
> 
> On 11/27/20 4:29 AM, Hans Petter Selasky wrote:
>> 
>> Is the problem always triggered by hald? If you disable hald in rc.conf, 
>> does the system run for a longer period of time?
> 
> It turns out that disabling ntpd let the system run for a longer period of 
> time - until I ran "sysctl sys" at which point I got a panic.
> 
> And this time the panic actually implicates amdgpu.ko, which is an 
> improvement:
> 
> 
> #9  0x in ?? ()
> #10 0x82a14c4e in amdgpu_device_get_pcie_replay_count ()
>from /boot/modules/amdgpu.ko
> #11 0x82a14b80 in sysctl_handle_attr () from /boot/modules/amdgpu.ko
> 
> #12 0x80c06cc1 in sysctl_root_handler_locked (oid=0xfe02133ff000,
> arg1=0xfe016e360980, arg2=-8724518803888, req=0xfe016e360980,
> tracker=0xf81099af6280) at /usr/src/sys/kern/kern_sysctl.c:184
> #13 0x80c0610c in sysctl_root (oidp=,
> arg1=0xf810aa27e650, arg2=-2100190360, req=0xfe016e360980)
> at /usr/src/sys/kern/kern_sysctl.c:2211
> 
> 
> Since it _is_ a problem in amdgpu, I'll stop this thread and re-post on 
> freebsd-x11.

FWIW, I am using amdgpu on a Ryzen 5 3500U system on a couple days old
-current (r368025). "sysctl sys" complains about "unknown oid 'sys'".
I am runing hald & ntpd.  I had a few amdgpu related panics initially
but they vanished once I added
PORTS_MODULES=graphics/drm-devel-kmod
to /etc/src.conf to compile it along with the kernel. I am running
GENERIC-NODEBUG. The machine gets rebooted when I install a new kernel
(usually once a week).

My guess is some weird interaction rather than something in amdgpu.



___
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: Please check the current beta git conversions

[Bakul Shah]

On Oct 3, 2020, at 3:14 PM, Steffen Nurpmeso  wrote:
> 
> And still "git fetch" fails with
> 
>  POST git-upload-pack (chunked)
>  error: RPC failed; curl 55 OpenSSL SSL_write: Broken pipe, errno 32
>  fatal: the remote end hung up unexpectedly
> 
> My config file is
> 
>  [core]
>repositoryformatversion = 0
>filemode = true
>bare = false
>logallrefupdates = true
>  [remote "origin"]
>url = https://cgit-beta.freebsd.org/src.git
>#url = https://github.com/freebsd/freebsd.git
>fetch = +refs/heads/releng/5.5:refs/remotes/origin/releng/5.5
>fetch = +refs/heads/releng/6.4:refs/remotes/origin/releng/6.4
>fetch = +refs/heads/releng/7.4:refs/remotes/origin/releng/7.4
>fetch = +refs/heads/releng/8.4:refs/remotes/origin/releng/8.4
>fetch = +refs/heads/releng/9.3:refs/remotes/origin/releng/9.3
>fetch = +refs/heads/releng/10.3:refs/remotes/origin/releng/10.4
>fetch = +refs/heads/releng/11.4:refs/remotes/origin/releng/11.4
>fetch = +refs/heads/releng/12.1:refs/remotes/origin/releng/12.1
>fetch = +refs/heads/stable/12:refs/remotes/origin/stable/12
>fetch = +refs/heads/main:refs/remotes/origin/main
>fetch = +refs/notes/*:refs/notes/*

FWIW, I have a bare repo with the following config file

[core]
repositoryformatversion = 0
filemode = true
bare = true
logallrefupdates = true
[remote "origin"]
url = https://cgit-beta.freebsd.org/src.git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/notes/*:refs/notes/*
[branch "main"]
remote = origin
merge = refs/heads/main

/usr/src is a worktree and everything seems to be working fine.

I manually converted to a bare repo (first testing this with a much
smaller repo) and fixed up various refs. But probably safer to
just start from scratch:

git clone --bare https://cgit-beta.freebsd.org/src.git
cd src.git
git fetch origin 'refs/notes/*:refs/notes/origin/*' # <<< not sure about 
this
# don't recall if I manually added the second fetch line in the config 
file.
# but notes get fetched fine; though I don't understand why 100MB+ get
# downloaded every time even though only a few files change.

git worktree add  main
git worktree add  stable/12

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

fatal error: 'cpuid.h' file not found

[Bakul Shah]

Trying "make -j8 buildworld" with a very recent tree (revision 366156).
This fails with

/usr/src/sys/contrib/openzfs/lib/libspl/include/sys/simd.h:34:10: fatal error: 
'cpuid.h' file not found
#include 

Could this be related to the flags I am using (in particular not
building CLANG)?

$ cat /etc/make.conf
MALLOC_PRODUCTION=yes
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/usr/obj/ccache

$ cat /etc/src.conf
WITHOUT_CLANG=yes

$ cat /etc/src-env.conf
WITH_META_MODE=yes

I do kldload filemon before buildworld.

Trying minimize incremental build time and don't really care to build
clang every time. [I'd appreciate any advice on how to further cut down
the build time]

If it matters, I am using the cgit-beta tree.

Thanks!

___
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: Plans for git

[Bakul Shah]

On Sep 18, 2020, at 11:21 PM, Warner Losh  wrote:
> 
> These are the main ones. The three down sides are lack of $FreeBSD$ support
> and tags in general.

Can a git hook be used for this?

> 
> Yes. I've started doing a series of short videos explaining the change, why
> we are doing it and what to do in the new world order. I'll be doing blog
> entries as well as turning that material into handbook entries. I have some
> of those written.
> 
> Does this help?

It would be useful to describe the development model (e.g. how major/minor
features get added etc), how to maintain multiple local branches (e.g.
release branch or -current) or working on more than one feature at a time etc.

Do you plan to move to something like the github review process?

When is the cutover supposed to occur?

The cgit-beta.FreeBSD.org and github trees are not identical the last
time I looked (mainly in meta data). Any reason for not keeping them
identical? I switched from the github tree to the cgit-beta tree.

FWIW, I have used sccs, rcs, cvs, subversion, mercurial, git & a few more.
I have used git exclusively for the last few years. I felt more comfortable
with git once I understood the on-disk storage model. The Pro Git book is
pretty good for that & more.

Thanks,
Bakul
___
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: System clock is slow

[Bakul Shah]

On Mar 10, 2020, at 9:24 AM, Theron  wrote:
> 
> On 2020-03-10 01:38, Peter Jeremy wrote:
>> Are you running NTP?  If so, is NTP maintaining lock and what is the
>> reported PLL frequency (ntpq -c kerni)?
> 
> Didn't show any useful difference, "kernel status: pll unsync" when I tested 
> this.

May take a while. ntpq -c peer should show a line with a leading *.
Though likely unrelated to your problem.

>> What does "sysctl kern.timecounter" report and have you tried using
>> any of the alternative timecounters listed in kern.timecounter.choice?
> 
> Indeed that reveals the problem:
> kern.timecounter.hardware: TSC-low
> (before regression)
> kern.timecounter.tc.TSC-low.frequency: 1296053807
> (after regression)
> kern.timecounter.tc.TSC-low.frequency: 13

In an old (amd 8150) -12.1 machine I see
kern.timecounter.hardware: TSC-low
kern.timecounter.tc.TSC-low.frequency: 1806045908
machdep.tsc_freq: 3612091816

In a new ryzen -current machine:
kern.timecounter.hardware: TSC
kern.timecounter.tc.TSC.frequency: 2096123148
machdep.tsc_freq: 2096123148

> Through some printf's in tsc.c I've determined that the 2.6e9 value is from 
> 0x16 CPUID which Intel says is only a nominal value not to be used, whereas 
> 2.592e9 value is from calibration.
> 
> /*
>  * Calculate TSC frequency using information from the CPUID leaf 0x15
>  * 'Time Stamp Counter and Nominal Core Crystal Clock'.  If leaf 0x15
>  * is not functional, as it is on Skylake/Kabylake, try 0x16 'Processor
>  * Frequency Information'.  Leaf 0x16 is described in the SDM as
>  * informational only, but if 0x15 did not work, and TSC calibration
>  * is disabled, it is the best we can get at all.  It should still be
>  * an improvement over the parsing of the CPU model name in
>  * tsc_freq_intel(), when available.
>  */
> 
> The implementation logic for when to use tsc_freq_cpuid() looks wrong to me; 
> it doesn't match what this comment implies.  Fallback to calibration when 
> calibration is unspecified should proceed when 0x15 fails regardless of what 
> 0x16 does.  (CC'd the authors).


As I understand it, if the user doesn't *explicitly* disable
frequency calibration, it must be calibrated. It may still be
skipped if there are no legacy devices. See around tsc.c:300.

What does sysctl machdep.disable_tsc_calibration return? Do you
see a line like the following in dmesg?

Skipping TSC calibration since no legacy devices reported by FADT and CPUID 
works

The Commit log says this:

x86: Fall back to leaf 0x16 if TSC frequency is obtained by CPUID and
leaf 0x15 is not functional.

This should improve automatic TSC frequency determination on
Skylake/Kabylake/... families, where 0x15 exists but does not provide
all necessary information.  SDM contains relatively strong wording
against such uses of 0x16, but Intel does not give us any other way to
obtain the frequency. Linux did the same in the commit
604dc9170f2435d27da5039a3efd757dceadc684.

Based on submission by: Neel Chauhan 
PR: 240475
Reviewed by:markj
Sponsored by:   The FreeBSD Foundation
MFC after:  1 week
Differential revision:  https://reviews.freebsd.org/D21777

> Switching to HPET or ACPI-fast gives the expected results.  Would there be 
> any reason to not use HPET provided I can cope with the performance 
> implications?

Have you looked at hpet(4), timecounters(4), clocks(7) manpages?
I don't know how up-to-date these manpages are
___
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: CVS removal from the base

[Bakul Shah]

On Sun, 04 Dec 2011 16:42:04 PST Julian Elischer jul...@freebsd.org  wrote:
 On 12/4/11 3:36 PM, Randy Bush wrote:
 
  i suspect that my install pattern is similar to others
 o custom install so i can split filesystems the way i prefer,
   enabling net  ssh
 o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer
   if it does not have emacs)
 o hack /etc/ssh/sshd_conf to allow root with password
 o rsync over ~root
 o hack /etc/ssh/sshd_conf to allow root only without-password
 o rsync over my standard /etc/foo (incl make.conf and src.conf)
   and other gunk
 o csup releng_X kernel, world, doc, ports
 o build and install kernel and world
 
  and then do whatever is special for this particular system.
 
  anything which would lessen/simplify the above would be much
  appreciated.  anything not totally obiously wonderful which would
  increase/complicate the above would not be appreciated.
 
 my suggestion is that the 'sysports' or 'foundation ports'  or
 'basic ports', (or whatever you want to call them) in their package
 form come with the standard install in fact I'd suggest that they
 get installed into some directory by default so that 'enabling' them
 ata later time doesn't even have to fetch them to do the pkg_add.
 
 They have pre-installed entries in /etc/defaults/rc.conf. and only 
 their rc,d
 files need to beinstalled into /etc along with their program files.
 They are as close to being as they are now with the exception of
 being installed in the final step instead of at the same time as the 
 rest of the stuff,
 and it allows them to easily be 'deinstalled' and replaced by newer 
 versions.
 
 Some of them would come from the current system sources and some of 
 them would be
 what are currently 'normal' ports but we consider them to be 'basic' 
 and 'extra supported'
 
 Examples of the first type would be bind, sendmail, cvs, and examples
 of the second type would be perl, bash, maybe python, and possibly a 
 very minimal set of the
 X11 packages.
 
 These are things we talk about having extra support for in the 
 installer anyhow.
 I also suggest that said packages include a plugin for 
 sysinstall/bsdinstall. so that it can ask its own
 quesitons during install.
 
A while back I had toyed with a config based approach. The
idea is you install a minimal system and then use one of the
predefined system configs to bring the system upto a desired
state.  The same config will use your local script of the same
name if one exists, to allow for local modifications.  The
same config (or an updated version) can be rerun after an
update.

Basically the idea is that you are dealing with a system as a
_whole_ for the purpose of install/update/convert/replicate.
You are capturing the personality or metadata of a system
a single file (it in turn relies on a small set of small text
files). This can be used for other purposes as well.

A config is essentially names of packages to install, variable
names, names of any pre/post external scripts to run, and
other included configs. But no executable logic here!

If this is used, a new release would also contain a repo for
every predefined script -- this makes it easy to see what
changed and deal with it.

Benefits:
- people can consistently customize their setup and keep
  it so after an upgrade
- what is included in the base system becomes largely
  irrelevant
- you can check/fix system personality at any time
- you can generate a local config easily
- can exactly replicate the same config on multiple machines
- can systematically change the personality of your system
- you can integrate this in sysinstall (and provide more
  flexibility)
- you can define your own specialized configs for whatever
  purpose.

To give you an idea:
syscfg install foo# install foo on a new installation
syscfg set foo# change existing (unconfigured) system to foo
syscfg convert bar# change existing (configured) system to bar
syscfg diff foo   # compare local system against foo
syscfg [-f] check   # check and optionally fix 
syscfg update

You would need to tell it where to get its data (either a
released ISO or a site). Lot of details would have to be
worked out.

Unfortunately I don't get to use FreeBSD much these days @
work and my home setup doesn't change much.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: No human readable message with g_vfs

[Bakul Shah]

On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous swel...@gmail.com  wrote:
 
 Do you mean perror(1)?
 
   $ perror 5
   Input/output error

I prefer mine:

$ errno () { grep ^#.*\\$*\\ /usr/include/sys/errno.h }
$ errno 5
#define EIO 5   /* Input/output error */
$ errno EIO
#define EIO 5   /* Input/output error */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: No human readable message with g_vfs

[Bakul Shah]

On Mon, 03 Jan 2011 22:21:51 +0300 Anonymous swel...@gmail.com  wrote:
 Bakul Shah ba...@bitblocks.com writes:
 
  On Mon, 03 Jan 2011 21:20:42 +0300 Anonymous swel...@gmail.com  wrote:
 =20
  Do you mean perror(1)?
 =20
$ perror 5
Input/output error
 
  I prefer mine:
 
  $ errno () { grep ^#.*\\$*\\ /usr/include/sys/errno.h }
  $ errno 5
  #define EIO 5   /* Input/output error */
  $ errno EIO
  #define EIO 5   /* Input/output error */
 
 perror(1) displays localized messages
 
   $ LANG=3Dja_JP.UTF-8 perror 5
   =E5=85=A5=E5=87=BA=E5=8A=9B=E3=82=A8=E3=83=A9=E3=83=BC=E3=81=A7=E3=81=99
 
   $ LANG=3Duk_UA.UTF-8 perror 5
   =D0=9F=D0=BE=D0=BC=D0=B8=D0=BB=D0=BA=D0=B0 =D0=B2=D0=B2=D0=BE=D0=B4=D1=83=
 -=D0=B2=D0=B8=D0=B2=D0=BE=D0=B4=D1=83

Yes, definitely useful. Perhaps strerror would be a better name?

 but I have to agree that knowing errno macro is useful

And you can use grep tricks :-)

$ errno '[dD]evice'
#define ENXIO   6   /* Device not configured */
#define ENOTBLK 15  /* Block device required */
#define EBUSY   16  /* Device busy */
#define EXDEV   18  /* Cross-device link */
#define ENODEV  19  /* Operation not supported by device */
#define ENOTTY  25  /* Inappropriate ioctl for device */
#define ENOSPC  28  /* No space left on device */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: limits to memory on amd64

[Bakul Shah]

On Tue, 09 Nov 2010 08:45:14 PST Julian Elischer jul...@freebsd.org  wrote:
 During the discussion at MeetBSD the question came up as to what the real
 limiting factors were with regard to how much RAM a system could have.
 it was put to us that the limit was currently around 512 GB, though no-one
 at teh discussion knew what the mechanism of the limitation was or 
 what might ligh beyond it.
 
 Could anyone who knows, pipe upt and let use know what the factors are,
 and if the current limit is overcome, what the next one after that will be?

You mean beyond architectural limits?

From Wikipedia:

Larger physical address space: The original
implementation of the AMD64 architecture implemented
40-bit physical addresses and so could address up to 1 TB
(2^40 bytes) of RAM. Current implementations of the AMD64
architecture (starting from AMD 10h microarchitecture)
extend this to 48-bit physical addresses and therefore
can address up to 256 TB of RAM. The architecture permits
extending this to 52 bits in the future (limited by the
page table entry format); this would allow addressing of
up to 4 PB of RAM.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Interpreted language(s) in the base

[Bakul Shah]

On Thu, 19 Aug 2010 20:35:59 +0200 C. P. Ghost cpgh...@cordula.ws  wrote:
 
 But seriously, the point isn't so much which specific interpreter
 we use (if we go down this road), it's about libraries: most
 sysadmin tasks require some basic networking and I/O,
 and a FFI to seamlessly call out C functions from .so libs.
 
 And, of course, instead of writing 1,001 sysadmin scripts
 with endless code duplication and reinventing of the wheel,
 common sysadmin tasks should also be made into reusable
 functions, grouped into modules.

Exactly what I had in mind.

  And we don't have to argue about which language. I would
  suggest setting up a wiki page to list all the system scripts
  people want to write and get cracking in your favorite
  language! May the best effort win :-) At the very least we
  will get some useful tools out of this effort. =A0I will
  certainly help out with Scheme.
 
 Funny idea. I only hope we won't end up with a typical
 post-dot-com young developer distribution, a la:
 
   60% PHP (yuck!)
   25% Java (and XML-everywhere)
   15% ${OTHERS}
 
 ;-)

If that is what people want then so be it :-)

But I think only little languages like forth, lua, sh, rc,
es  scheme have small footprint interpreters that start up
fast and are reasonably efficient.

Anyway, system programming in Scheme is what interests me and
something I already tinker with on and off. If anyone is
interested (in helping or just playing with it), let me know
privately (but *not* on this mailing list).
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Interpreted language(s) in the base

[Bakul Shah]

On Fri, 20 Aug 2010 21:33:08 +0200 =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= 
d...@des.no  wrote:
 C. P. Ghost cpgh...@cordula.ws writes:
  After all LISP-like syntax is *still* more common and prevalent
  than Lua, e.g. in Elisp, guile, esh, scsh and a lot of other apps
  that use it as a small language. So we can expect more users
  to be at least partially familiar with it. And there *are* lightweight
  MIT- or BSD-licensed scheme interpreters out there too:
 
 Considering that the majority of people who might be interested in using
 this know *neither* Lisp *nor* Lua, my vote is for Lua, because people
 who are familiar with neither will be more open to learning Lua, which
 resembles other languages they already know, than Lisp, which doesn't.

[Couldn't resist responding but my last message on this tangent]
If you are open to learning a C like language, one can
provide a C like frontend syntax to most of Scheme  to a
degreee similar to lua.  Like C/Lua etc. Scheme is also a
block structured language.  Apart from syntax, the key
differences are:

- everything is an expression.
- variables are not typed (anything can be assigned to a var)
- functions can be anonymous, nested and returned from other functions
- symbols  lists are built-in unlike in C
- no built-in structs, unions or ptrs
- a very powerful macro facility
- support for continuations

ksm for instance implements a C like syntax.

See http://square.umin.ac.jp/hchang/ksm/ref/ksm_13.html

[Yes, I am aware of Dylan and what happened to it but still
 think this can be a useful effort]
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Interpreted language(s) in the base

[Bakul Shah]

On Thu, 19 Aug 2010 18:00:54 +0200 C. P. Ghost cpgh...@cordula.ws  wrote:
 On Wed, Aug 18, 2010 at 3:43 PM, Andrew Reilly arei...@bigpond.net.au wro=
 te:
  On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote:
  got any other suggestions?
 
  This is very much a sorry I asked question, but is none-the
  less quite a good one, given the size of the hole to be plugged.
 
  I think that a reasonable answer for this sort of thing might be
  one of the dynamic languages that compiles to C, like (perhaps)
  one of the schemes (chicken, gambit-C, bigloo, etc). =A0You get
  the benefit of flexibility and dynamism with good regexp and
  data structure ability, good performance, and only requiring the
  build tools available in the base system, as long as you don't
  want to be the developer: just ship the C code (as well as the
  source, of course).
 
  Unfortunately it seems that quite a lot of people have issues
  with lisp syntax these days.
 
 +1 for a scheme shell, but not for the heavy-weight variety that
 compiles to C, as that would tie them to a subset of ${ARCH}es.

+1 for Scheme! It has a lot in its favor (see below).

But this is an abstract discussion. Until there are plenty of
useful system scripts (in one of these languages) that people
really want, nothing is going to change.

There is no reason to wait until something is in the base.
And we don't have to argue about which language. I would
suggest setting up a wiki page to list all the system scripts
people want to write and get cracking in your favorite
language! May the best effort win :-) At the very least we
will get some useful tools out of this effort.  I will
certainly help out with Scheme.

-- bakul

Scheme has many interpreters  compilers so you can write
Scheme scripts to be interpreted and at some point compile
them for better performance if necessary. Scheme has some
excellent text books, a precise definition for a given
standard, it changes slowly, has IDEs and so on. If you stick
to the R4RS subset, almost every scheme interprpter/compiler
will handle it.  It has a very powerful macro facility.  Its
interpreters can be very small. s9fes and tinyscheme for
example are about 5K lines of C code each.  Stalin compiles
Scheme to some extremely tight C code by doing global program
analysis.  And there are many other systems in between.  slib
is a library of a lot of useful packages that can be used
with most Schemes.  Many of these interpreters can be used
from C/C++.  Many provide a C-FFI to call C functions.
Tinyscheme packages all of Scheme state in a single structure
so one can easily create a separate Scheme interpreter per
thread.  There is even a vi clone written in 4K lines s9fes
Scheme!  Still beta but already useful.

These many choices can be very confusing but we can pick one
and stick to writing R4RS portable Scheme code.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: bsdgrep does not work with tail -f | grep combination

[Bakul Shah]

On Tue, 03 Aug 2010 20:21:56 +0200 Gabor Kovesdan ga...@freebsd.org  wrote:
 Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu:
  Hi,
 
  It seems bsdgrep does not work when piped from tail -f.
  I'm running r210728.
 
  term0$ jot 10  /tmp/1
  term0$ tail -f /tmp/1 | grep 0
  [no output]
 
  otherterm$ jot 10  /tmp/1
  [no output to term0]
 
  =
 
  with GNU grep:
 
  term0$ tail -f /tmp/1 | gnugrep 0
  10
  otherterm$ jot 10  /tmp/1
  [on term0]
  10
  10
 
 I've checked on 8.0 and GNU grep doesn't output anything either for me. 
 If you use tail -f, you will enter more lines and end it with EOF, won't 
 you? And then BSD grep will process the input and print out matches. I 
 don't think it's bad behaviour in itself but if you can explain why you 
 think it's bad I'm willing to change it.

This is more fundamental, not just limited to grep.  tail -f
never closes its stdout channel so the next process in the
pipeline will never seen an EOF on its stdin and must
continue processing its input. Try this:

rm -f /tmp/1; touch /tmp/1
tail -f /tmp/1 | cat 
while sleep 1; do date  /tmp/1; done

Notice how cat doesn't quit. In fact

tail -f /tmp/1 | bsdgrep ''

must behave exactly the same as 

tail -f /tmp/1 | cat

and so must this:

tail -f /tmp/1 | cat | bsdgrep ''

bsdgrep when used this way doesn't quit but doesn't do
anything either (including printing what tail -f spits out
from existing file data). This is just a bug.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Importing clang/LLVM into FreeBSD HEAD

[Bakul Shah]

On Mon, 31 May 2010 09:52:48 +0200 Roman Divacky rdiva...@freebsd.org  wrote:
 
 I would like to propose to integrate clang/LLVM into FreeBSD HEAD
 in the near future (days, not weeks).
 
 clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly
 replace gcc. It is BSDL-like licensed. The sources are ~45MB (the
 svn checkout is 97MB). Clang/LLVM is written in C++.
 
 Clang can compile all of FreeBSD on i386/amd64 including world and booting
 kernel. Other architectures that are close to working are MIPS, PowerPC
 and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM
 sources and the build infrastructure and this is what we aim to integrate
 at first.

 The import of clang/LLVM was discussed at the toolchain summit May 10th
 but I would like to hear your opinion. I got approval from core@ on
 importing it.
 
 So please share your support or resistance to the idea of importing clang.
 
 Roman Divacky

I already use clang for some things but I think the issue
here is not support/resistance but something else:

* IMHO for a change of this nature the core needs to publish
  a set of clear acceptance criteria for importing clang.
  Can this be done?

* Since clang doesn't support all the archs, what is the plan
  for unsupported archs?
  a. Is FreeBSD going to have both compilers in the base?
  b. Is the project drop these FreeBSD ports? or
  c. Do people have to import gcc from ports to build these
 FreeBSD ports?

* What about ports?

* Basically the core needs to lay out a roadmap.

It is clear that not everyone has the same view of what the
acceptance criteria might be so publishing it would help
people understand what to expect.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Importing clang/LLVM into FreeBSD HEAD

[Bakul Shah]

On Mon, 31 May 2010 12:33:18 MDT M. Warner Losh i...@bsdimp.com  wrote:
 
 :  It is clear that not everyone has the same view of what the
 :  acceptance criteria might be so publishing it would help
 :  people understand what to expect.
 : 
 : nothing changes for the ports, there's an ongoing project to enable
 : ports to be usable with clang (or some other compiler) but thats
 : orthogonal to this.
 
 Part of the problem with this thread is that the whole, agreed plan
 wasn't laid out at the first part of it, so people are freaking out
 about what the plans are for the future.  They were discussed and
 first order agreement was reached at the tool chains summit.  But part
 of the agreement was to post the whole agreement so people know and
 understand the various trade offs.
 
 I think that would go a long way towards answering the questions that
 are being raised and to quell the visceral reaction that I've seen in
 this thread

Exactly!

I still urge core to lay out a clear plan. And don't forget
to indicate the acceptance criteria to be met for each step!
[Not to add bureaucracy but to ensure that nothing falls
through the cracks]

Can't speak for others but I am very appreciative of all the
work put in enthusiastically by Roman and others to get clang
into FreeBSD. Exciting to have a real alternative to gcc!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: swapon vs savecore dilemma

[Bakul Shah]

  Is fsck really that memory heavy so that it needs swap?
 
 Yes, if you have a huge FS.
 
 The problem is that the checking of the CG bitmaps during an fsck
 require that you have all the bitmaps in core

Hmm
For a one TB FS with 8KB block size you need 2^(40-13) bits
to keep track of blocks.  That is 2^24 bytes or 16Mbytes.
That doesn't seem so bad (considering that you really should
have a lot more RAM if you are playing terrybytes of data).

 My suggestion (which has been my suggestion all along) is to add
 two date stamped CG bitmap bitmaps somewhere (my favorite place
 for this is to steal space at the front of inode 1, which is used
 only rarely, since people don't use the whiteout feature, and
 which can be made compatible with whiteouts, in any case).

This is the old stable storage idea.  You need a generation
number rather than a date stamp but the idea is the same.
Something needs to be done so that time to fsck depends on
the outstanding FS traffic at the time of the crash rather
than the size of the FS (especially when you are dealing with
multi terabytes of data).
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Anyone working on fsck?

[Bakul Shah]

UFS is the real problem here, not fsck.  Its tradeoffs for
improving normal access latencies may have been right in the
past but not for modern big disks.  The seek time  RPM have
not improved very much in the past 20 years while disk
capacity has increased by a factor of about 20,000 (and GB/$
even more).  IMHO there is not much you can do at the fsck
level -- you stil have to visit all the cyl groups and what
not.  Even a factor of 10 improvement in fsck means 36
minutes which is far too long.  Keeping track of 67M to 132M
blocks and (assuming avg file size of 8k to 16k) something
like 60M to 80M files takes quite a bit of time when you are
also seeking all over the disk.

A few ideas:

When you have about 67M (2^26) files, ideally you want to
*avoid* checking as many as you can.  Given access times, you
are only going to be able to do a few hundred disk accesses
at most in a minute.  So you are going to have only a few
files/dirs that may be inconsistent in case of a crash.  Why
not keep track of that somehow?

If you need about 1GB of space to store the state of a TB
file system that needs to be checked, may be it _should_ be
*stored* in a contiguous area on the FS itself.  1GB is about
0.1% of space.

Typically only a few cyl grps may be inconsistent in case of
a crash.  May be some info about which cyl groups need to be
checked can be stored so that brute force checking of all
grps can be avoided.

Typically a file will be stored in one or a small number of
cyl groups.  If that info. is stored somewhere it can speed
things up.

Extant based allocation will reduce the number of indirect
blocks.  But may be this is not such a big issue if most of
your files fit in a few blocks.

Anyway, support for all of these have to be done in the
filesystem first before fsck can benefit.

If instead you spend time optimizing just fsck, you will
likely make it far more complex (and potentially harder to
get right).

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Anyone working on fsck?

[Bakul Shah]

 Now, before we go off and design YABFS, can we just get real for
 a second ?

I leave it to others to design YAFS, I just wanted to
complain about this one :-)  Every few years I seriously look
at speeding up fsck but give up.  I remember even asking
about it a few years ago on one of these groups.

 I have been tending UNIX computers of all sorts for many years and
 there is one bit of wisdom that has yet to fail me:
 
   Every now and then, boot in single-user and run full fsck
   on all filesystems.
 
 If this had failed to be productive, I would have given up the
 habit years ago, but it is still a good idea it seems.

Even now I use fsck in forground since the background fsck
was not stable enough the last time I used it.  But I
remember thinking fsck was taking too long for as long as I
have used it (since 1981).

 Personally, I think background-fsck is close to the ideal situation
 since I can skip the boot in single-user part of the above
 profylactic.

Anything that runs for half hour or more in fg is likely to
take longer in bg.  What happens if the system crashes again
before it finishes?  Will bg fsck handle that?  Am I right in
thinking that it can not save files in /lost+found?

In general I am very uneasy with bg fsck -- when I am validating
something I don't want to be creating new stuff.

 If you start to implement any sort of journaling (that is what you
 talked about in your email), you might as well just stop right at
 the clean bit, and avoid the complexity.

No, I didn't suggest journaling, I suggested storing all
state in a contiguous area (or a small number of such areas).
indirect blocks, keeping track of free blocks, etc.  You can
still do a completely exhaustive fsck but it won't be
exhausting to you.

Journaling is also a good idea:-)

 Optimizing fsck is a valid project, I just wish it would be somebody
 who would also finish the last 30% who would do it.

I am skeptical you will get more than a factor of 2
improvement without changing the FS (but hey, that is 3 hours
for Julian so I am sure he will be happy with that!).

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Anyone working on fsck?

[Bakul Shah]

 You talk like I have a choice :-)
 I cannot change ufs/ffs and even if I could the clients wouldn't go for
 it.

What about changing the size of block size or cyl grp size?
Do they change things much?

 The problem space is
 
 Fsck of UFS/FFS partitions is too slow for 200GB+ filesystems.

 The solution space can not contain any answer that includes redefining
 UFS/FFS. Welcome to the real world. :-)

I am so glad I have a separate machine for every few GB of
disk space :-)

So may be you can have on a multi-processor solution.  I'll
try to come up with more useful suggestions given your
constraints

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Anyone working on fsck?

[Bakul Shah]

  UFS is the real problem here, not fsck.  Its tradeoffs for
  improving normal access latencies may have been right in the
  past but not for modern big disks.
...
 Sorry, but the track-to-track seek latency optimizations you
 are referring to are turned off, given the newfs defaults, and
 have been for a very long time.

I was thinking of the basic idea of cylinder groups as good
for normal load, not so good for fsck when you have too many
CGs. I wasn't thinking of what fsck does or does not do.

 Basically, the problem is that for a BG fsck, it's not possible
 to lock access on a cylinder group basis, and then there is a hell
 of a lot of data on that drive.

Note that Julian said 6 hours to fsck a TB in the normal
foreground mode.

 What Julian needs is a Journalling or Log-structured FS.  

All that Julian wants is a faster fsck without mucking with
the FS!

While I agree with you that you do need a full consistency
check, it is worth thinking about how one can avoid that
whenever possible.  For example, if you can know where the
disk head is at the time of crash (based on what blocks were
being written) it should be possible to avoid a full check.

 The easiest way to do this is to provide some sort of domain
 control, so that you limit the files you have to check to a
 smaller set of files per CG, so that you don't have to check
 all the files to check a particular CG -- and then preload the
 CG's for the sets of files you *do* have to check.

If you have to visit a CG (during fsck) you have already paid
the cost of the seek and rotational latency.  Journalling
wouldn't help here if you still have a zillion CGs.

 Another way of saying this is... don't put all your space in a
 single FS.  8-).

Or in effect treat each CG (or a group of CGs) as a self
contained filesystem (for the purpose of physical allocation)
and maintain explicit import/export lists for files that span
them.

 The problem with having to (effectively) read every inode and
 direct block on the disk is really insurmountable, I think.

That is why I was suggesting putting them in one (or small
number of) contiguous area(s).  On a modern ATA100 or better
disk you can read a GB in under a minute.  Once the data is
in-core you can divide up the checking to multiple
processors.  This is sort of like a distributed graph
collection: you only need to worry about graphs that cross a
node boundary.  Most structures wille contained in one node.

Even for UFS it is probably worth dividing fsck in two or
more processes, one doing IO, one or more doing computation.

  Typically only a few cyl grps may be inconsistent in case of
  a crash.  May be some info about which cyl groups need to be
  checked can be stored so that brute force checking of all
  grps can be avoided.
 
 This would work well... under laboratory test conditions.  In
 the field, if the machine has a more general workload (or even
 a heterogeneous workload, but with a hell of a lot of files,
 like a big mail server), this falls down, as the number of bits
 marking unupdated cylinder groups becomes large.

Possible -- it is one of the ideas I can think of.  I'd have
to actually model it or simulate it beyond handwaving to know
one way or other.  May be useful in conjunction with other
ideas.

 ...AND... The problem is still that you must scan everything on
 the disk (practically) to identify the inode or indirect block
 that references the block on the cylinder roup in question, and
 THAT's the problem.  If you knew a small set of CG's, that needed
 checked, vs. all of them, it would *still* bust the cache, which
 is what takes all the time.


 Assume, on average, each file goes into indirect blocks.

On my machine the average file size is 21KB (averaged over
4,000,000 files).  Even with 8KB blocksize very few will have
indirect blocks.  I don't know how typical my file size
distribution is but I suspect the average case is probably
smaller files (I store lots of datasheets, manuals,
databases, PDFs, MP3s, cvs repositories, compressed tars of
old stuff).

But in any case wouldn't going forward from inodes make more
sense?  This is like a standard tracing garbage collection
algorithm.  Blocks that are not reachable are free.  Even for
a 1 TB system with 8K blocks you need 2^(40-13-3) == 16Mbytes
bitmap or some multiple if you want more than 1 bit of state.

 The problem is reverse mapping a bit in a CG bitmap to the file
 that reference it... 8^p.

Why would you want to do that?!

 Multithreading fsck would be an incredibly bad idea.

It depends on the actual algorithm.

 Personally, I recommend using a different FS, if you are going
 to create a honing big FS as a single partition.  8-(.

There are other issues with smaller partitions.  I'd rather
have a single logical file system where all the space can be
used.  If physically it is implemented as a number of smaller
systems that is okay.  Also note that now people can create
big honking files with video streaming at the 

Re: Problems with Current XFree86

[Bakul Shah]

 Since it works with 4.7-STABLE it must(?) be a current problem
 more than a XFree86 problem. Or?

I had the same problem -- something to do with files left
over from the original 4.7 installation.  Cured by
deinstalling XFree86-* ports, renaming /usr/X11R6 to
something else (in case something was needed), and then
reinstalling everything.  Thanks to portupgrade this was
pretty easy.  I reused the old XF86Config.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

 Good point. We can re-implement random() internally with arc4rand().
 
 Objections?

Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever).  If you go change
the underlying algorithm or its parameters one can't generate
the same sequence from the same seed when repeating a test.
Some chip bug symptoms show up after hours/days of simulation
time and only with specific inputs so repeatablity is a
requirement.

The old 16 bit rand() was broken enough that it didn't matter
much (read: _I_ don't care) if its behavior got changed but
random() has a pretty long cycle and enough randomness to
be very useful and it *is* used.

*Please* don't change random() -- if you do that you will
break existing tests.  It is not a matter of just rewriting
tests since there is no easy way to predict  which input
triggers a certain bug -- one can try to use the same
binaries but that prevents fixing of bugs in the test
generation code itself.

If you think random() is not random enough for your purposes,
go create a new function with a *new* name.

[I see from his latest email that PHK remembered the old
discussion!]

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

 As I said, I don't know how big a concern this is.  But last time
 it was enough of a concern to make us keep rand() as it was.

[I know you are talking about rand() but Mark Murray's
earlier email about wanting to re-implement random() really
concerned me so I want to make sure my point gets across]

Not changing random() was of real concern to me when I was
doing chip simulations.  ASIC design verification folks won't
be happy if the rug is pulled out from under them.  In
general crypto and simulation needs are different and I don't
trust the crypto guys to look out for the simulation guys!

I don't care any more if rand() is changed but _please_ leave
random() alone!  And it would be nice to indicate *why* in
the source code for the next time this discussion comes up.

Thanks!

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

 RC4 is _utterly_ repeatable, given a particular seed/key.

May be but it is not the same as the current random().  Also,
I know you will want to change it the next time some one
points out a problem with RC4.

 Yes. And it breaks, and we have a complainant.

So create a new function!  Or use a different function to
generate or initialize the seed.  I think one has to treat a
behavior bug very carefully.  If enough people are depending
on it, it pretty much has to get enshrined as part of the
spec -- sort of like the timeout arg to select(). 

 The random() function in libc is documented to give the same
 pseudo-random output for a particular seed. if you link your
 program against a _different_ libc, you cannot expect your
 results to follow a particular number sequence.

There is an expectation that on subsequent releases of the
same OS things continue to work.

Historically rand() and random() under unix have been used
the most for simulation.  [aside: Earl T. Cohen (the author
of random(3)) also has had a lot to do in this area]

Why not totally separate all uses of crypto related random
number generator uses from the traditional simulation use?
That way you can change crypto_random to your heart's content
as the crypto needs change (as they will).

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

 Maybe I missed something, but why cannot you just rip random() from libc, 
 rename it to bakul_shah_random() and use that in your testing code?  Then you
 are safe from any changes to random(), and indeed have a portable RNG if your
 host OS changes.

Yes, *I* can do it but I don't work at every place they do
simulation!  If in the extreme you are suggesting that a
portable application shouldn't rely on any OS features, you
are of course right but that kind of makes mockery of any
claims of compatibility.  The point of compatibility is to
not break interfaces unless there is a significant benefit.

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

 a restriction on the OS.  If FreeBSD makes random2() using RC4 to avoid 
 changing rand() or random(), will people then start relying on random2()'s 
 behaviour, and when someone finds a problem in RC4, then the next will be 
 random3()?

What I am suggesting is to leave random() as it is and
guarantee its behavior won't change and add cryto_random() or
whatever, and indicate it *may* change.

 Would you have a problem with changes in the TCP/IP stack changing the 
 content of packets sent out when you connect(), if it breaks your TCP/IP 
 simulations?

This is not a similar situation.

Note that it is rand() that is broken, not random() as can be
seen by modifying Kris Kennaways' test so I don't see why
Mark Murray was talking about changing it in the first place.

#include stdlib.h
#include stdio.h

int main() {
int i;

for(i = 1; i = 1000; i++) {
srandom(i);
printf(%d: %d\n, i, random());
}
}

1: 1804289383
2: 1505335290
3: 1205554746
4: 1968078301
5: 590011675
6: 290852541
7: 1045618677
8: 757547896
9: 54915
10: 1215069295
11: 1989311423
12: 1687063760
13: 1358590890
14: 2146406683
15: 762299093
16: 462648444
17: 1227918265
...

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

 Would you prefer that we defined random() as
 
 int
 random(void)
 {
   static int retval = 0;
 
   return retval++;
 }

No because that would be a change from the exisiting random()
behavior :-)

As I indicated in my earlier email random() is not broken,
srand() is (as corrected by Andrey Chernov) so you won't be
fixing any bugs by changing random().  If you guys had left
the original rand() alone we wouldn't be discussing any of
this

random(3) also provides an initstate() call which presumably
allows you to change the amount of randomnes.  So here is
another suggestion: why not fold your algorithm change in
that function?  For example,

initstate(seed, RC4, 3);

changes the algorithm to RC4.  Yes, this is a change in the
interface but one I am sure most people can live with.

  There is an expectation that on subsequent releases of the
  same OS things continue to work.
 
 Where is that expectation guaranteed?
 Where is that expectation supported?

This expectation is a reasonable one.  Most commerical OSes
do a good job of maintaining compatibility.  IRIX certainly
did a pretty good job of it.  FreeBSD also does a pretty good
job on the whole.

 The two are related topics.

Yes, but not the same.

 Consider the (joking reference to) elephant-free biology. :-)

The way things are going we will be there pretty soon :-(

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

 Since you keep talking about random(), I must conclude you're
 knee-jerking, since we're not discussing that function.  Please stay
 on-topic :-)

Read through the thread.  In particular see Mark's message
[EMAIL PROTECTED] where he
says

Good point. We can re-implement random() internally with arc4rand().

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

  another suggestion: why not fold your algorithm change in
  that function?  For example,
  
  initstate(seed, RC4, 3);
  
  changes the algorithm to RC4.  Yes, this is a change in the
  interface but one I am sure most people can live with.
 
 No. Evil interface change. #ifdef hell while programs try to
 figure out OS differences.

How so?  This or a similar change is upward compatible in
that the existing behavior is left unchanged and it gives you
a way to replace the algorithm.

The basic issue is just what is the expected and (implicitly)
promised behavior of random().

AFAIK all random(3) implementations in various versions of
Unix come from Earl's original 4.2BSD implementation so in my
view the _expected_ behavior is to see the _exact_ same
sequence starting from a given seed.  This function is called
random() but it is equivalent to a mathematical function
which must provide the same sequence for the exact same
input.

You and a number of other people are saying that the exact
sequence is *not* promised so you are free to change the
algortithm as long as the statistical distribution is
uniform.

Earl chose to name his new implementation random() [even
though clearly he was replacing rand(3)] probably to not
break any existing scripts.  In my view any further behavior
change should either use a new name or make an upward
compatible change.

Now the question is whether perl uses system provided
random() or rand() or its own since perl is used extensively
in ASIC verification.

Any way, this is my last email on this subject since neither
one of us is convincing the other.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

 Last 10 digits.
 
  FreeBSD   Redhat   SunOS 
 660787754660787754645318364
 3275486913275486911583150371
 2009993994   2009993994   715222008
 1653966416   1653966416   1349166998
 1074113008   1074113008   566227131
 2142626740   2142626740   1382825076
 1517775852   1517775852   583981903
 1453318125   1453318125   1453942393
 6196078076196078071952958724
 1999863931999863931599163286

Interesting  The SunOS output exactly matches random(3)
behavior from 4.3BSD!  In fact random() remained the same for
4.3BSD-Reno, -Tahoe, 4.4BSD-Alpha and Net2.

4.2BSD random() behavior is different from all of the above.
There was real bug-fix between 4.2BSD and 4.3BSD.

I don't know when the FreeBSD/Redhat change was made or if it
broke any statistical properties.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: rand() is broken

[Bakul Shah]

 Interesting  The SunOS output exactly matches random(3)
 behavior from 4.3BSD!  In fact random() remained the same for
 4.3BSD-Reno, -Tahoe, 4.4BSD-Alpha and Net2.
 
 4.2BSD random() behavior is different from all of the above.
 There was real bug-fix between 4.2BSD and 4.3BSD.
 
 I don't know when the FreeBSD/Redhat change was made or if it
 broke any statistical properties.

FYI:
The FreeBSD change was made in -r1.4 of random.c by Andrey in
Oct 1996.  The previous version of random.c behaves exactly
the same as the one in  4.3BSD, SunOS and AIX.  I am sorry I
was too busy with other things then and missed this change.

Andrey refers to an OCT 1988 CACM paper by Park  Miller
Random number generators: good ones are hard to find as a
justification for this change.

Also FYI: NetBSD random(3) matches the 4.3BSD random().
Haven't checked OpenBSD.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Style fixups for proc.h

[Bakul Shah]

 Julian Elischer writes:
  I don't know about the protection with a '_'.
  
  It's not standard and usually the name matches that used in the actual
  function.
 
 When the prototype parameter name matches a local variable, the C compiler
 (and lint) whine about clashes between names in local/global namespace.

According to C99, a function prototype has its own scope or
name space.  It terminates at the end of the function
declarator.  Basically naming a parameter in a function
prototype is an aide to the human user; it is not needed for
correct compilation[1] so this warning is bogus.  As the
spec says in section 6.7.5.3 (according the draft I have)

The identifiers [naming parameters] are declared for
descriptive purposes only and go out of scope at the end
of the [prototype] declaration.

I can't see what actual error is avoided by this warning.

 2 ways to fix this are to protect the prototype argument names with the
 _, or to remove the argument name altogether.

Why not fix the compiler  lint instead of cluttering up
declarations?

-- bakul

[1] Except for what is needed for declaring flexible or
variable length array parameters.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Style fixups for proc.h

[Bakul Shah]

  I can't see what actual error is avoided by this warning.

s/actual/potential/

 
 If a named prototype clashes with something in global scope,
 isn't it still a shadowing issue?  They should probably never
 be *in* scope.

Nothing is being shadowed.  Paramater names in a function
prototype (as opposed to a function definition) are simply
not relevant to the compiler (their distinctness, type and
positions are but not the actual names).  No potential bug is
being hidden by saying, for example,

int x;
int foo(int x);

It is perfectly fine to later define foo as

int foo(int y)
{
return x + y;
}

The compiler should simply discard any parameter names in a
prototype once the prototype is digested and C programmers
need to know that.  Now if parameter y shadows a global y one
may want to be warned about it.

Garrett gives an example:

 Say you have an object and a function declared in global scope:
 
   int foo;
   /* many lines of declarations */
   /* perhaps this is even in a different file */
   void bar(quux_t foo);
 
 At some point, somebody changes the spelling of `foo' and adds a
 preprocessor macro for compatibility:
 
   union baz {
   int foo;
   struct frotz *gorp;
   } foobaz;
   #define foo foobaz.foo
 
 What happens to the declaration of that function?  Well,
 
   void bar(quux_t foobaz.foo);
 
 is a syntax error.

This sort of problem can occur when you have any two objects named the
same.  Consider:

struct dumb { int foo; };

After the above redefinition this defn won't compile (even
after his amendation:-).

Not naming parameters is one solution but with some loss of
perspicuity.  Consider:

int* make_matrix(int, int);
versus
int* make_matrix(int rows, int columns);

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: pppd not working on latest current 2002-10-20

[Bakul Shah]

  Until pppd is taught to create the interface if one doesn't
  exist, this information needs to be in /usr/src/UPDATING.
 
 pppd doesn't need to be taught to create the interface.  Rather it needed
 to learn to check for ppp support in a non-stupid way.  The following
 patch should do it as well as making pppd do the right thing when
 support isn't compiled in, but a module is available.  It should make
 things work with a GENERIC kernel.

`device ppp' was already defined in my kernel config file so
there was no need to kldload if_ppp.  But I had to run
`ifconfig create ppp' to make things work.

I don't much like auto kldloading modules from suid programs.
A simple hack is to just add ifconfig create ppp in rc.local.
Also kldload if_ppp if needed.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: pppd not working on latest current 2002-10-20

[Bakul Shah]

 Here's a new patch that gives the user more of a hint at how to add PPP
 support and only loads the module if they are actully root.  How's this
 look?

I still don't like it.  How to explain

I don't think it is pppd's responsibility to muck with
modules.  It is like mount kldloading a disk driver module.
Neither program has any business guessing which module name
goes with which device/feature.

What if I want to run ppp over ethernet over atm?  I know you
can't do this today but in general the trend should be to
make protocol modules more flexible not less.  Hardwiring
module names is analogous to making a function non-reentrant.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: pppd not working on latest current 2002-10-20

[Bakul Shah]

 Brooks Davis wrote:
  This isn't going to have an effect on the ability to use kernel ppp for
  other things.  The tty orientation of pppd and the outdated, unmodular
  design on ppp(4) have taken care of that.  This patch gives people
  the functionality they want (pppd just working) without any major
  entanglements (the whole function is 20 lines).

I meant reuse of pppd.  From what I remember, pppd does a lot
of the control plane stuff (IPCP, CHAP...) which is useful
for other ppp-over-foo combinations.  In general a different
module or set of modules may implement ppp-over-foo so
hardwiring the module name in pppd is not a good idea.  Now
you are probably thinking: In that case why not just default
to if_ppp and otherwise use an environment variable?.  This
would add complexity and another potential security hole.

If someone
  wants to make pppd work on arbitrary devices we can deal with that when
  it happens and I frankly doubt it's ever going to since we've got
  netgraph to do that with.

Existance of an alternative is not an argument in favor of
allowing something to rot since doing so limits your flexibility.

Terry writes:
 Depending on the value of sysctl kern.module_path, if the if_ppp
 module does not exist, and one of the path components is writeable,
 then this would permit you to abuse the pppd to load arbitrary modules
 into the kernel.

Thank you for explicating the security argument!  I'll also
point out that hardwiring module names makes it harder to
experiment with replacement modules (i.e. I may want to
develop if_super_duper_ppp).

 But by the same token, mount and ifconfig have the same problems;
 on the other hand, unlike pppd, they are not suid root.

AFAIK mount does no autoloading (i was using it as another
place where one might be tempted to use autoloading).  In
general any tool (command) that relies on a resource or
feature can have the same problem of the resource not
existing.  Just how far does one go to discover/autoload
resources?  Should we try to fetch it from a trusted
repository?  Should we try to compile it if we have the
sources?  It is a slipper slope.  A new programmer next year
will assume all the old programmers were fools and to him it
will be obvious the module sources fetched afresh and
compiled.  Okay, I am exaggerating.

 On general principles, loading modules with commands, rather than the
 kernel doing it automatically, is a bad idea.  But FreeBSD already
 does this in a number of commands, because it lacks a certralized
 feature demand support facility.

Another area for endless debating:-)  But don't worry, I'll stop soon!

If only the kernel is allowed to load them on demand, there
needs to be a way for modules to declare the feature-set they
provide and for the kernel to follow administrative policies
while autoloading them.

 You could also make security arguments on the basis of what if the
 administrator didn't want the machine to be able to be configured
 for PPP -- on purpose?

This is a policy argument.  Thanks for bringing that up!

 As it is, this patch does nothing worse than add to an existing
 mess brought about by not having an integrated demand-load facility;
 I don't see this as a problem... if there;s a problem, fix it first
 in mount and ifconfig, before you complain about this patch.

It adds needless complexity.  In any case, complain is too
strong a word!  I just pointed out something that I didn't
like based on the principles I try to follow when writing
software.  Consider it in the leading a horse to water
category:-)  If the horse thinks it is just a mirage, that
too is fine with me!  We can argue about that too. ducks

I have used up my 2 cents many times over, so over and out!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: pppd not working on latest current 2002-10-20

[Bakul Shah]

 On Fri, Oct 25, 2002 at 06:15:55PM +, Dave Evans wrote:
  Is anyone using pppd on CURRENT.  somewhere between may and October it
  seems to have broken.  My KERNEL is GENERIC, my sources are dated cvs
  -D2002-10-20, but I now get a message about needing facilities in the
  kernel. However, the kernel has many ppp entry points, I haven't
  modified GENERIC which loads the ppp device, I've tried loading modules
  with ppp in their name all to no avail.
 
 You need to create an interface first. Run ifconfig ppp create.

Until pppd is taught to create the interface if one doesn't
exist, this information needs to be in /usr/src/UPDATING.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

ldconfig in /etc/rc /etc/rc.d/ldconfig

[Bakul Shah]

If the ldconfig_insecure flag is set in /etc/rc.conf,
ldconfig doesn't do anything useful at startup time except
complain.  The following patch should fix it.

diff -ur /usr/src/etc/rc ./rc
--- /usr/src/etc/rc Tue Sep 17 21:02:01 2002
+++ ./rcSun Sep 22 16:49:19 2002
@@ -692,9 +692,10 @@
 # add your own entries or you may come to grief.
 #
 ldconfig=/sbin/ldconfig
+ldc_flags=
 case ${ldconfig_insecure} in
 [Yy][Ee][Ss])
-   ldconfig=${ldconfig} -i
+   ldc_flags=-i
;;
 esac
 if [ -x /sbin/ldconfig ]; then
@@ -705,7 +706,7 @@
fi
done
echo 'ELF ldconfig path:' ${_LDC}
-   ${ldconfig} ${_LDC}
+   ${ldconfig} ${ldc_flags} ${_LDC}
 
# Legacy aout support for i386 only
case `sysctl -n hw.machine_arch` in
@@ -719,7 +720,7 @@
fi
done
echo 'a.out ldconfig path:' ${_LDC}
-   ${ldconfig} -aout ${_LDC}
+   ${ldconfig} -aout ${ldc_flags} ${_LDC}
;;
esac
 fi
diff -ur /usr/src/etc/rc.d/ldconfig ./rc.d/ldconfig
--- /usr/src/etc/rc.d/ldconfig  Tue Sep 17 21:02:03 2002
+++ ./rc.d/ldconfig Sun Sep 22 16:48:12 2002
@@ -21,7 +21,8 @@
case ${OSTYPE} in
FreeBSD)
ldconfig=${ldconfig_command}
-   checkyesno ldconfig_insecure  ldconfig=${ldconfig} -i
+   ldc_flags=
+   checkyesno ldconfig_insecure  ldc_flags=-i
if [ -x ${ldconfig_command} ]; then
_LDC=/usr/lib
for i in ${ldconfig_paths}; do
@@ -30,7 +31,7 @@
fi
done
echo 'ELF ldconfig path:' ${_LDC}
-   ${ldconfig} -elf ${_LDC}
+   ${ldconfig} -elf ${ldc_flags} ${_LDC}
 
# Legacy aout support for i386 only
case `sysctl -n hw.machine_arch` in
@@ -44,7 +45,7 @@
fi
done
echo 'a.out ldconfig path:' ${_LDC}
-   ${ldconfig} -aout ${_LDC}
+   ${ldconfig} -aout ${ldc_flags} ${_LDC}
;;
esac
fi

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Bluetooth stack for FreeBSD

[Bakul Shah]

 Yes. we are aware of the work and we are pleased that it is hapenning, but
 few of us have even SEEN any bluetooth stuff yet.. 
 certainly in the US it's not yet being marketted a lot.

Fry's Electronics in the SF bayarea has a bunch of bluetooth
gadgets.  Go to www.outpost.com and search for 'bluetooth'.

USB adapters, pcmcia card, printer adapter, connectors for
Palm and iPAQ etc.  The printer adapter looks just like a
standard paraller port connector with a RJ11 or RJ45 socket
on one side (you can hook up a serial cable to it too).

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: aout support broken in gcc3

[Bakul Shah]

 You are blowing this out of proportion and not actually reading
 what people are proposing.  So far, the comments are about
 removing a.out support from the base compiler and offering
 a.out binutils and gcc _as ports_.

A port is fine -- but this was proposed much later in the
thread.

  Unfortunately there is no such direct back-pressure in the
  open source community and developers usually don't have a
  long term view.
 
 Thank you for insulting our intelligence.

Sorry you see it that way -- I certainly didn't mean to
insult anyone's intelligence.  It is just the way I see it --
programmers want to program neat new things (or clean up
code or make thinge more elegant, faster, more modular, more
generic and so on) and users just want to continue using what
they are comfortable with -- even when they want to play with
new and shiny things.  I believe both groups should
participate in deciding the direction FreeBSD takes.  That is
what will bring out the best without breaking old things.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: aout support broken in gcc3

[Bakul Shah]

   Where exactly does GCC fit into the mix, making this impossible?
  
  They compile Lisp (etc) to a C file, which they compile (with gcc) to
   ^^^
 actually with as(1), because gcc is only generates assembler file,
 which is then translated into the object file by assembler (as).
 Assembler by itself is part of binutils, not a compiler suite.

I suspect Richard Tobin was using the generally accepted
meaning for a compiler as one that translates a source
program into object code (machine language).  In any case, it
is cc1 that generates an assembly file.  gcc is just a driver
program that calls various subprograms.

Richard's main point with which I totally agree is that
please do not take away the ability to generate and grok
a.out files *if at all possible*.  A number of Lisp systems
as well as Scheme one use ld -A  friends to do what he
described.  In general, please do not break backward
compatibility.

meta-discussion
Seems to me that most of the FreeBSD developers are not heavy
3rd part software users.  Consequently they (the developers)
do not realize that even when sources are available it is not
always easy to update them to support changes that break old
code -- due to lack of time or money or inability or
inexperience to change the 3rd party software or whatever.
When sources are not available, you are up the proverbial
creek.

You may say just continue running old freeBSD kernels but the
constant stream of security fixes makes hard to justify doing
that.

IMHO what is needed is a strong voice for the *users* (along
with hackers/developers) in influencing the direction FreeBSD
takes -- right now if you don't hack FreeBSD code, you don't
get listened to very much.  This is like letting a builder
build a house, or worse, letting an architect design a house
without input from the people who are going to live in it
[trust me, you want a 4000 sq ft house on your 4500 sq ft
lot, with humongous walkin closets, tiny bedrooms, a big
master bathroom with large french windows in the shower (so
what if it is facing your neighbor's living room windows only
10 ft away)].

In a commercial setting it is the user who ultimately pays
the development costs so they do get listened to (or the
company dies).  As an example, on a modern SGI machine you
can still run 20 year old binaries -- providing such
compatibility is a pain and not pretty but to long time
users' their dusty decks are very valuable.

Unfortunately there is no such direct back-pressure in the
open source community and developers usually don't have a
long term view.
/meta-discussion

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: pkg_add broken by POLA breakage in tar

[Bakul Shah]

My recollection matches what Bruce says (and I have been
using unix since when version 7 was the latest and greatest).
At least the SUN OS 5.6 man page I could locate online says
this:

 The o function modifier is only valid with the x function. p
 Restore the named files to their original modes, and ACLs if
 applicable, ignoring the present umask(1). This is the
 default behavior if invoked as super-user with the x
 function letter specified. If super-user, SETUID and sticky
 information are also extracted, and files are restored with
 their original owners and permissions, rather than owned
 by root.

This superuser behavior is what allows one to use tar as an
archiving program.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: mount_nfs -T breakage

[Bakul Shah]

 Yes, that code is very broken indeed. It probably was supposed to
 call __rpc_setconf(udp) and not getnetconfigent(udp), but that
 seems to pick up an ipv6 address. I think the best plan is to go
 back to the way that part of the code was before revision 1.10.
 
 Could you try the following patch?

Thank you for the patch!  Yes, it works.  Right after I sent
out my message I tried an almost identical patch which also
worked but, as I said I don't understand this code, didn't
have time to understand it and my patch seemed a bit hacky so
I kept quiet.  Actually this whole routine seems hacky -- why
look up udp when you are told explicitly to use tcp?  Oh
well, I should keep quiet until I really understand it:-)

Thanks again!

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

mount_nfs -T breakage

[Bakul Shah]

TCP mount of nfs seems to be broken.

# mount bar:/usr /mnt
[tcp] bar:/usr: RPCPROG_NFS: RPC: Unknown protocol

I tracked this down to lib/libc/rpc/rpcb_clnt.c.  Seems like
the problem is in __rpcb_findaddr_timed().

diff -r 1.9 rpcb_clnt.c 
--- rpcb_clnt.c 22 Mar 2002 23:18:37 -  1.9
+++ rpcb_clnt.c 11 Jul 2002 16:23:04 -  1.10
...[deleted]...
@@ -672,13 +731,15 @@
  * starts working properly.  Also look under clnt_vc.c.
  */
 struct netbuf *
-__rpcb_findaddr(program, version, nconf, host, clpp)
+__rpcb_findaddr_timed(program, version, nconf, host, clpp, tp)
rpcprog_t program;
...[deleted]...
@@ -710,22 +777,31 @@
 */
if (strcmp(nconf-nc_proto, NC_TCP) == 0) {
struct netconfig *newnconf;
+   void *handle;
 
-   if ((newnconf = getnetconfigent(udp)) == NULL) {
+   if ((handle = getnetconfigent(udp)) == NULL) {
+   rpc_createerr.cf_stat = RPC_UNKNOWNPROTO;
+   return (NULL);
+   }
+   if ((newnconf = __rpc_getconf(handle)) == NULL) {
+   __rpc_endconf(handle);
rpc_createerr.cf_stat = RPC_UNKNOWNPROTO;
return (NULL);
}
client = getclnthandle(host, newnconf, parms.r_addr);
-   freenetconfigent(newnconf);
+   __rpc_endconf(handle);
} else {
client = getclnthandle(host, nconf, parms.r_addr);

Notice how newnconf, the second arg of getclnthandle(), is
derived.  Previously it was the output of getnetconfigent()
while now it is output of __rpc_getconf().  It expects its
arg to be of type ``struct handle*'', but it is given an arg
of type ``struct netconfig*''  The two structs are not congruent.

I don't really understand this code so I don't know what the real
fix is.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

suspend bug

[Bakul Shah]

Try this:

$ csh
% su
Password:
% stop $$

Suspended (signal)
%fg

At which point you will lose you login shell.

Prior to KSE one could switch between an su'ed shell and a
normal shell at will by using stop $$ and fg.

Is this breakage considered a bug or a feature?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Interesting panic very early in the boot

[Bakul Shah]

 I believe setting DISABLE_PSE in the config file and rebuilding
 will make this go away.

Terry, thanks for the suggestion but that didn't do it.
Time to review recent changes and single step the kernel.
BTW, how do you stop the kernel before it panics?  It
panics so early that there is no time for sending a break.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Interesting panic very early in the boot

[Bakul Shah]

 That there could be a real error in that code surprises me, since
 Peter really knows what he's doing, even if that low in the
 hardware, there are undocumented interactions that even Intel's
 errata doesn't seem to know about.

Turns out the workaround is to use DISABLE_PG_G.

Two things made me try this.  One: In his commit of pmap.c
and locore.s on 7/12 7:56 Peter had this to say:

 +--
 |- Try and fix some very bogus PG_G and PG_PS interactions that were bad
 |  enough to cause vm86 bios calls to break.  vm86 depended on our existing
...
 |New option:  DISABLE_PG_G - In case I missed something.
 +--

Two: cvs diff -r1.336 -r1.337 of i386/pmap.c showes that
#ifdef SMP was changed to ifndef DISABLE_PG_G and it is in
here that pfeflag is set (pfeflag is what guards the code at
the crash site!).

 set boot_ddb

Didn't do this.

 set boot_gdb

Did this.  I though the above two were mutually exclusive options.
boot_ddb should be renamed to start_in_debugger or something.

Though boot -d is what I was really looking for.

 higher/later code, the root cause is catually in locore.s.  Happy
 bug hunt!  ;^).

Thanks but looks like I easily escaped from the hunt this
time :-)

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Interesting panic very early in the boot

[Bakul Shah]

I've run into a very similar bug -- the kernel panics almost
right after it is started by the loader.  With remote gdb
I've traced it to this point so far:

(kgdb) target remote /dev/cuaa0
Remote debugging using /dev/cuaa0
pmap_set_opt () at /usr/src/sys/i386/i386/pmap.c:449
449 if (*pte)
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: shared library handler failed to enable breakpoint
(kgdb) where
#0  pmap_set_opt () at /usr/src/sys/i386/i386/pmap.c:449
#1  0xc0307c64 in pmap_bootstrap (firstaddr=3146924, loadaddr=0)
at /usr/src/sys/i386/i386/pmap.c:403 
#2  0xc03056b2 in getmemsize (first=4947968)
at /usr/src/sys/i386/i386/machdep.c:1473
#3  0xc0305e2f in init386 (first=4947968)
at /usr/src/sys/i386/i386/machdep.c:1817
(kgdbl
444 /* Turn on PG_G for text, data, bss pages. */
445 va = (vm_offset_t)btext;
446 endva = KERNBASE + KERNend;
447 while (va  endva) {
448 pte = vtopte(va);
449 if (*pte)
450 *pte |= pgeflag;
451 va += PAGE_SIZE;
452 }
453 invltlb();  /* Insurance */
(kgdb) p/x va
$2 = 0xc012be70

I can't get to pte for some reason.  So hand computing vtopte(va) we get

(kgdb) p/x btext
$3 = 0xc012be70
(kgdb) p PTmap
$7 = 0xbfc0
(kgdb) p/x PTmap+0xc012b
$8 = 0xbff004ac

This address matches the page fault address.  It is a
supervisor read, protection violation fault.

More details:

This is with today's (July 16) kernel (synced at about 5PM
PDT) on a Ppro system.  This system can take two PPros but
I've plugged in just one Pentium Pro.  It has 64MB ECC
memory.  I'll continue investigating but I haven't been in
this part of code for ages hence the call for help!

If it matters, a kernel built from sources before the KSE
changes works fine on this machine.

Thanks for any hints.

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: Please test PAUSE on non-Intel processors

[Bakul Shah]

$ dmesg | head | tail -4 
CPU: AMD Athlon(tm) XP 1700+ (1466.51-MHz 686-class CPU)
  Origin = AuthenticAMD  Id = 0x662  Stepping = 2
  
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
  AMD Features=0xc048b19,AMIE,DSP,3DNow!
$ ./pt
Testing PAUSE instruction:
Register esp changed: 0xbfbff860 - 0xbfbff824

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: multi default routes in freebsd !?

[Bakul Shah]

 BGP is a better idea (of course).
 
 You might also consider using BGP.
 
 And have I mentioned BGP?  8-) 8-).

Whether to use BGP/OSPF is orthogonal to multipath use.  Both
OSPF and BGP allow you to install multiple next hops.  Adding
multipath support requires, at a minimum, changing struct
rtentry to store multiple `gateways' (which are really next
hops).  You also need to fix up code to do the right thing
when adding a new route or deleting an existing route (for
example, a route is not considered dead until paths all next
hops are dead).  For forwarding a packet you can always use
the first next hop to start with but very likely you'd want
to change the forwarding code and use some policy to pick a
next hop.  Typically you'd want to use the same next hop for
a given source so as to not mess up TCP RTT calculations.

start meta discussion
Seems to me that the needs of client, server and router
machines are different enough that the networking stack code
needs to be much more flexible.  One can always put in the
most elaborate solution and just not use fancier features for
client machines but then every one pays the cost of
complexity.  Not sure what is the right thing to do here.
Anyone care to pontificate?

The same situation exists w.r.t. a number of other features.
/start meta discussion

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: mergemaster(8) broken -- uses Perl

[Bakul Shah]

 Paul Herman [EMAIL PROTECTED] wrote:
  On Sun, 19 May 2002, Dima Dorfman wrote:
  
   How about fixing ls(1) to output the numeric mode if asked to?
  
  That's good, but while you're at it you'd probably want to get
  *everything* out of (struct stat) and print it numerically (device,
  flags, atime since epoch, etc.)  You could do this in ls(1), but
  I'll have a patch for fstat(1) soon (working on it) that gives you:
  
  bash$ /usr/obj/usr/src/usr.bin/fstat/fstat -s /tmp /kernel
  INODE  DEVSIZE BLOCKS MODE   FLAGS  LNK UID GID ATIME  MTIME CTIME 
 NAME
  235226304 4114305  8096   100555 40 1   0   0   1021779222 
10217403541021740354 /kernel
  56651  226304 512  4  041777 00 6   0   0   1021787523 
10217876571021787657 /tmp
  
  so you can parse it however you like.  Either way, ls(1) or
  fstat(1), as long as you can get the info you need.  :-)
 
 This looks much better than my extention.  I look forward to seeing
 this get into the tree.

I have a yet another variation, called `stat'.  It is like
ls(1) except you specify what stat fields you want using a
printf style format string.  I added -n flag to print out
numeric values instead of symbolic ones where it makes sense.
I originally wrote it many years ago because access to stat
fields from shell scripts is such a pain.  Yours for asking.

$ stat -h
Usage: stat [-a | -f format] [-h] [-n] [-L] files...
  where options are:
-a  print all attributes
-f format   print using a printf like format
-h  this help message
-L  follow symbolic links
-n  prints numeric values not symbolic values
The -f format is as follows:
  \ escapes are as in printf
  any other non % char is printed as is, %% prints a single %
  a stat field is printed using %[-][width][.width]letter format.
  - for left justification, width[.width] is as for %s format of printf
 letter can be one of:
   a  file access time
   b  allocated blocks
   c  inode change time
   d  dev
   f  flags
   g  group
   G  generation
   l  links
   m  file modify time
   n  file name
   p  permissions: r=read w=write x=exec S=suid/sgid s=suid/sgid+x
   T=sticky t=sticky+x
   r  raw dev
   s  size
   t  type: b=block c=char d=dir -=file p=fifo s=socket l=symlink w=whiteout
   u  user
 The default format is %t%p %2l %-6u %-6g %9s %m %n\n
 Format for the -a option is %a|%b|%c|%d|%f|%g|%G|%i|%l|%m|%p|%r|%s|%t|%u|%n\n

$ stat stat
-rwxr-xr-x  1 bakul  bakul  22523 May 18 23:46:16 2002 stat
$ stat -a stat

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: mergemaster(8) broken -- uses Perl

[Bakul Shah]

 $ stat -a stat

Oops!  A few lines got eaten!

$ stat -a stat
May 19 00:24:42 2002|48|May 19 00:24:42 2002|291846|-|bakul|0|262301|1|May 19 00:24:42 
2002|rwxr-xr-x|1095744|23996|-|bakul|stat
$ stat -a -n stat
1021793082|48|1021793082|291846|0|1001|0|262301|1|1021793082|755|1095744|23996|10|1001|stat

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

stat(1) (was Re: mergemaster(8) broken -- uses Perl

[Bakul Shah]

 the trick nicely (but is too ``complicated'', and I'd still like
 having a tool that allows userland to call stat/fstat(2):

You are not alone; a number of stat(1) commands seemed to
have popped up over the years.  My friend @ SGI told me IRIX
also has such a command.  I liked its options so I modified
mine to match its options as well as kept the option to
specify output format.

New options:

-a atime
-c ctime
-d dev
-g group
-i inode
-k kind (dir/file/fifo/symlnk/char/block/socket/whiteout)
-l links
-m mtime
-p permissions
-r rdev
-s size
-t all three times
-u user

-q quite (print numeric values, no syntactic sugar)
-f fd fstat on file descr. fd

For BSD stuff I added

-F flags
-G generation
-b blocks
-B blocksize

Also,
-L use lstat instead of stat
-n print name
-% fmt user specified format

fmt specification as shown in my previous email, except use
%k for kind and %t for printing all three times.

By default it prints all the stat fields instead of mimicing
ls -lTd as before.  You can specify STATFMT env. var for
a default format.

Example:

$ stat -p stat
rwxr-xr-x
$ stat -p -q stat
755

Not having used SGI's stat command I don't know what output
format it uses.

Paul Herman asks in a separate email if there is a happy
medium.  I don't think so.  One can use ls(1) for a more
human readable format.  stat(1) is really for script use.
Even the -% format is for that (to avoid having to pull out
the ginsu knife of awk/sed/perl for common uses).  About the
best I can do in 300 or so lines of code and that is already
a lot of lines for something like this.

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: size of /usr/src

[Bakul Shah]

Your questions belong to freebsd-questions!

 I created a separate partition for /usr/src (around 420MB) and cvsup ran
 out of space.  Can someone give me a rough idea of how big it is?  Also,
 I should be able to use growfs (after booting off of a floppy) to increase
 the size of the partition (if the slice has space), right? How about moving
 partitions - is there an easier way than creating a partition at the end
 of the slice and copying partitions down?

Are you creating a 5.0-CURRENT or a 4-STABLE /usr/src?

On a -STABLE:
$ du -s /usr/src
355799  /usr/src

On a -CURRENT:
$ du -s /usr/src
389637  /usr/src

FFS likes to have about 10% free space + add a few more (may
be 4%) for the inodes space.  So you need a partition of at
least 450MB.  You need to leave another 20% ~ 50% free for
future source fat (second law of computer thermodynamics).  A
partition of 1GB wouldn't hurt!

You need another 40MB or more for each kernel on whichever
partition you build them.  More if you turn debugging on.  Instead
of building kernels in /usr/src/sys/compile, you can do

cd /usr/src
make buildkernel KERNCONF=foo

to build them in /usr/obj/usr/src/sys/.

You don't need to boot from a floppy -- just unmount the
partition.  In case of the root partition you can growfs if
you boot in single user.  I believe initially the root
partition is mounted read-only so growfs change are safe.  I
would reboot immediately afterwards though.

For moving partitions I would use dump/restore to/from a
networked machine rather than copying them around.  For that
you may need to boot from a floppy.

Or you can just install released kernels and do something
worthwhile (like build some furniture) in the time you will
save :-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: RFC: hack volatile bzero and bcopy

[Bakul Shah]

 well this is th idea, because I think that bcopy is probably a safe
 operation 
 on the volatile structures if the driver knows that they are presently
 owned by it.. (e.g. mailboxes)

*probably* safe?  For truly volatile memory bzero  bcopy are
*not* safe.   Anyone remember the origial 68000's `clr'
instruction that did read followed by write to clear memory?
You _can_ use that clr instn in bzero if the passed in ptr
does not point to volatile memory.  bcopy can also use
efficiency tricks if the src  dst are not aligned on the
same 4 byte boundary.  AMD 29k for example had an `extract'
instruction that allowed unaligned copying at memory
bandwidth.  But usually one punted on boundary conditions and
didn't think twice about refetching a word.  One can't be so
cavalier if bcopy accepted volatile ptrs.  You can use
similar tricks on systems with wide cache lines and some of
these tricks would be illegal on volatile memory.

 out-of order is probably ok for a buffer if you know that it's
 presently yours to write into.

If the area being bcopied/bzeroed has this behavior why not
remove the volatile from the struct ptrs instead of fixing
bcopy/bzero?

 2/ add to the prototype of bzero and bcopy so that volatile pointers are
 acceptable 
 arguments. (I don't see any reason to not do this).

Because the (informal) defn of bcopy/bzero does not allow
volatile arguments.  You are wagging the dog.

Why not just cast these ptrs at the call sites where you
_know_ bcopy, bzero use is safe.  That sort of documents what
is going on without opening a big hole.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS

[Bakul Shah]

  $ size scheme 
 textdata bss dec hex filename
6134244763480   69298   10eb2 scheme
 
 Is that statically-linked?  I'm curious to know the size of the bootloader
 forth footprint.  The loader is about 150k, so I'm sure you could probably
 fit a nice Scheme interpreter in under that size... ??

Dynamically linked.  Here is the statically linked size:

$ size scheme
   textdata bss dec hex filename
 127659   110929236  147987   24213 scheme

Note that this is misleading because in order to build a
standalone binary you'd have to reduce libc dependence quite
a bit.  Basically avoid anything that makes a syscall.  You
can also throw out printf and friends, which will save you
over 10KB!  On the other side you'd have to add loader
specific code (either in Scheme or in c).

Here is the /boot/loader size for comparison sake:

textdatabss dec hex
4096147456  0   151552  25000

  Tinyscheme is a mostly complete R5RS Scheme (R5RS is the
 
 You can also conditionally-compile the components to make a smaller
 footprint.  I'm highly in favor of Scheme replacing 4th...  It's a very
 easy language to learn (only 11 special forms) yet still powerful (you
 can't pass code as data in BASIC ;).  If you replace the boot loader
 interpreter, pick Scheme over LISP.  There are lots of implementations:
 siod, scm, mit-scheme, MzScheme, and tinyscheme are among the better ones.

Indeed.

But ultimately someone has to do the actual work for this to
go beyond mere wishful thinking.  I'd be happy to help out
(but not take on the whole task) if anyone braves the
naysayers :-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS

[Bakul Shah]

  I doubt if the bootloader will ever change from FORTH, but if it
  does, I suggest LISP as the preferred choice on a short-list of
  potential replacements.
 
 Show us a suitable LISP interpreter, then.

I don't know what size constraints the bootloader has to have
but the smallest two lisp interpreters I have found are:

$ cd /usr/ports/lang/slisp/work/slisp-1.2/src
$ size slisp
   textdata bss dec hex filename
  17872 6163584   220725638 slisp

$ wc *.h *.c
  67 3212266 extern.h
  69 3352053 slisp.h
 9272438   15990 funcs.c
 189 7304707 lexer.c
 147 4583232 main.c
 287 8326358 object.c
 136 4703370 parser.c
18225584   37976 total

slisp has most of the common lisp constructs.

$ cd ~/lang/Scheme/tinyscm-1.27
$ size scheme 
   textdata bss dec hex filename
  6134244763480   69298   10eb2 scheme
$ wc *.h *.c
  12  33 247 dynload.h
 34411369221 scheme.h
 126 2922589 dynload.c
4445   12353  125421 scheme.c
4927   13814  137478 total

Tinyscheme is a mostly complete R5RS Scheme (R5RS is the
closest thing to a Scheme standard) -- everything except
complex and rational number types, bignums, hygenic macros
and call-with-values and unwind-protect.  You can probably
subset it quite a bit to make it far smaller (e.g. the real
number type and advanced math functions to avoid linking in
libm).  If it matters to you, it has a BSD style licence.

http://tinyscheme.sourceforge.net/home.html
http://tinyscheme.sourceforge.net/tinyscheme-1.27.tar.gz

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

skipping mouse pointer

[Bakul Shah]

I upgraded my system from the -current sources as of Aug-1 to
Nov-4 and find that now the mouse pointer skips while
dragging -- the pointer tracks mouse motion fine for a while,
then freezes and then jumps to a new location quite a few
pixels away.  The same thing happens under X as well as on a
virtual console.  Though the effect is not as pronounced on
a virtual console.  The new things I added were

device  random
options NETGRAPH
options COMPAT_LINUX
options FFS_EXTATTR
options NOBLOCKRANDOM

Also, rc.conf is considerably different since I hadn't upgraded
it in quite a while.  Has anyone else run into this?  Of course
I will remove the new options and see if the symptom goes away
but I thought I'd ask here as well...

Thanks,

-- bakul


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Archive pruning

[Bakul Shah]

 Do we really need 5 year old history?

That really depends on your point of view.

"Those who cannot remember the past are condemned to repeat it"
-- Santayana

"The only thing we learn from history is that we learn nothing from history."
-- Hegel

I am with Hegel in the very long term but what is the rush
about pruning?  Set a cron job to ask this in the year 2037!
In the short term it is valuable to trace back the genesis of
various features/bugs.  With cvs annotate you can even find
out who put in a feature or bug and bug that person about it
(as I was just this past week about something I had written
over four years back).  The networking code is so convoluted
that having all the history (which we don't) can be very
valuable in unravelling all the development strands.

-- bakul

PS: Of course, having a complete history is not the same as
reading and remembering it all but at least you have a
chance

What is missing is a tool that to easily browse through old
revisions (tkdiff is nice but not enough).  If such a tool
were available there would be many source code historians!

PPS: We should have a complete history *somewhere*.  You are
of course free to extend cvsup to prune so that *you* don't
have to keep it all.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Kernel config utility

[Bakul Shah]

 So, would having a kernel config utility help us get better
 reviews?  I was thinking about something like an explorer-type
 thing that was divided into two panes.  On the left would be
 LINT.  Here, we would have icons representing the various
 devices.  For example, we could ahve an icon representing an
 ethernet card, another icon representing a serial port, etc.  On
 the right hand side we would have the custom kernel config file. 
 You could just drag the icons over to the right hand side to add
 devices to your kernel config.  And, of course, you could always
 just delete the icons you don't need.

You have just described some file system operations!

left pane:  ls LINT
right pane: ls KERNEL
drag an icon:   cp LINT/device/ethernet KERNEL/device

 By clicking on the icons, a properties pane would show the
 properties for this device.  Of course, there should be some way
 to represent options, such as DEVFS or SOFTUPDATES.

property pane:  vi KERNEL/ethernet
options:touch KERNEL/options/DEVFS
echo 2048  KERNEL/options/NMBCLUSTERS

 Of course, I like using vi better, but I've heard some people
 complaining about "how hard it is to configure a FreeBSD
 kernel."

Most of us like the convenience of editing one file but I
think what these `some people' are asking for is explicit
structure.  In a config represented by a plain file the
structure is implicit and the flat structure makes it hard to
group related things so you have to read comments (if any and
hopefully uptodate) to understand what option applies to what
object.  A directory would provide that structure (and allow
for extensions that you wouldn't even try with a flat file).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: removing enigma(1)

[Bakul Shah]

 With the FreeBSD 4.0 code freeze fast approaching, are there any
 compelling reasons to keep enigma (src/usr.bin/enigma) in the 
 source tree?

How dare you be so anti-bloat, living so close to Redmond?:-)
[But otherwise a nice place, Seattle.  I used to live there]

Enigma is just a format converter at this point and should be
left around (after renaming it crypt -- which is how it is
known on all Unix versions older than 10 years).  Some of us
old fogeys still have old encrypted files exhumed, from moldy
old files for which crypt is useful (and not just for
reburying).  crypt should be left around *somewhere*.  If you
have to throw something out, throw our perl [ducking for
cover...:-]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

440fx builtin pnp `soundcard' doesn't work anymore under current

[Bakul Shah]

Running rvplayer crashes the system.  Catting a small .au
file works but a large one panics the system so I think the
problem may just be the drq difference.  I know a number of
people in the FreeBSD crowd have this system (a Toshiba
Equium 6200M -- a `good' buy 15 months back) so this can't be
an isolated problem.  I will be tracking this down but there
is some bootstrap time involved and may be someone has
already done this...

Thanks for any help!

-- bakul

I don't have the panic message handy at the moment but can
generate it if it'll help.

demsg reports:

pcm0: CS4236B at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0

My old /kernel.config used to say

pnp 1 0 os enable port0 0x534 port1 0x388 port2 0x220 irq0 5 drq0 1 drq1 3

[note: this used to work with an older current from June]

Kernel config file has

controller pnp0
device pcm0

pnpinfo dump [note: this shows drq 1  3]

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID CSC0b35 (0x350b630e), Serial Number 0x
PnP Version 1.0, Vendor Version 1
Device Description: CS4236B Audio

Logical Device ID: CSC 0x630e #0
Device Description: WSS/SB
TAG Start DF
Good Configuration
DMA: channel(s) 1 
8-bit, not a bus master, count by byte, , Type A
DMA: channel(s) 0 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5  - only one type (true/edge)
I/O Range 0x534 .. 0x534, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x8, len 0x4
[16-bit addr]
I/O Range 0x220 .. 0x220, alignment 0x20, len 0x10
[16-bit addr]
TAG Start DF
Acceptable Configuration
DMA: channel(s) 1 3 
8-bit, not a bus master, count by byte, , Type A
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5 7 9 11 12 15  - only one type (true/edge)
I/O Range 0x534 .. 0xffc, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x8, len 0x4
[16-bit addr]
I/O Range 0x220 .. 0x260, alignment 0x20, len 0x10
[16-bit addr]
TAG Start DF
Sub-optimal Configuration
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5 7 9 11 12 15  - only one type (true/edge)
I/O Range 0x534 .. 0xffc, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x3f8, alignment 0x8, len 0x4
[16-bit addr]
I/O Range 0x220 .. 0x300, alignment 0x20, len 0x10
[16-bit addr]
TAG End DF

Logical Device ID: CSC0001 0x0100630e #1
Device Description: GAME
TAG Start DF
Good Configuration
I/O Range 0x200 .. 0x200, alignment 0x8, len 0x8
[16-bit addr]
TAG Start DF
Acceptable Configuration
I/O Range 0x208 .. 0x208, alignment 0x8, len 0x8
[16-bit addr]
TAG End DF

Logical Device ID: CSC0010 0x1000630e #2
Device Description: CTRL
I/O Range 0x120 .. 0xff8, alignment 0x8, len 0x8
[16-bit addr]

Logical Device ID: CSC0003 0x0300630e #3
Device Description: MPU
TAG Start DF
Good Configuration
IRQ: 9  - only one type (true/edge)
I/O Range 0x330 .. 0x330, alignment 0x8, len 0x2
[16-bit addr]
TAG Start DF
Acceptable Configuration
IRQ: 9 11 12 15  - only one type (true/edge)
I/O Range 0x300 .. 0x3f8, alignment 0x8, len 0x2
[16-bit addr]
TAG End DF
End Tag

Successfully got 44 resources, 4 logical fdevs
-- card select # 0x0001

CSN CSC0b35 (0x350b630e), Serial Number 0x

Logical device #0
IO:  0x0534 0x0534 0x0534 0x0534 0x0534 0x0534 0x0534 0x0534
IRQ 5 0
DMA 1 0
IO range check 0x00 activate 0x01

Logical device #1
IO:  0x 0x 0x 0x 0x 0x 0x 0x
IRQ 0 0
DMA 4 4
IO range check 0x00 activate 0x01

Logical device #2
IO:  0x 0x 0x 0x 0x 0x 0x 0x
IRQ 0 0
DMA 4 4
IO range check 0x00 activate 0x00

Logical device #3
IO:  0x 0x 0x 0x 0x 0x 0x 0x
IRQ 0 0
DMA 4 4
IO range check 0x00 activate 0x00


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message