Re: maketz.sh problems with distrib build
On Sat, Sep 27, 2014 at 10:46 AM, wrote: > On Sat, 27 Sep 2014 09:02:52 +0300 >> On Sat, Sep 27, 2014 at 7:10 AM, wrote: >> > i encounter this error when building the (RAMDISK_CD) distrib kernel: >> > usage: maketz.sh DESTDIR >> ... >> > maybe the method i have been using to build distrib is outdated. currently >> > i do: >> > # (cd /usr/src/distrib/special/libstubs && make) >> > # cd /usr/src/distrib/i386/ramdisk_cd && make >> > which i got some years ago from one of these lists. is this still the >> > preferred >> > method? >> >> I don't think that was ever correct. The procedure for building a >> release is documented in release(8). >> >> (Why does that procedure install into a clean directory and assemble >> the release out of that? To absolutely guarantee that it cannot pick >> up a file left over in the running install from a previous version.) > > i guess it isn't clear, but i was never trying to make the release, only the > kernel. i've reconfigured them for live cd's and such. You are building the ramdisk, which is part of the release. You may be able to skip some of the steps involved because you don't want the .tgz outputs, but if you want to use the scripts that OpenBSD provides for this then you need to follow the base steps, including setting DESTDIR and installing into that. Is it worth your time to change those scripts locally (and maintain those changes as we evolve the scripts for *our* purposes) instead of just running them and then ignoring half the results? How much is your time worth? > also, i am subscribed to the list. We can't tell that or read your mind. The default assumption is that replies should go to both the poster and the list; you're welcome to set the Reply-To on your messages to point to the list if you don't want the direct message. Philip Guenther
Re: page zeroing
> Date: Fri, 26 Sep 2014 21:01:38 +0200 (CEST)
> From: Mark Kettenis
>
> The diff below adds a kernel thread that makes memory pages filled
> with zeroes without olding the kernel lock. The idea is that this
> should speed up MP systems because the kernel can do some useful work
> in parallel with other things, and could lower the latency on all
> systems because (userland) memory page allocation will be faster. The
> thread runs at the absolutely lowest priority such that we only run it
> if we don't have anything else to do.
>
> But this could also slow down some systems though, because zeroing
> pages can thrash the caches in your system.
>
> So I'd like to see this diff tested on a wide variety of systems, and
> hear back from people how this diff affects their OpenBSD systems.
> Subjective reports are ok; hard benchmarks are better.
>
> One thing to look at when you're running this diff is the output of
> "vmstat -s". It will report something like:
>
> 2146380 zeroed page hits
> 34258 zeroed page misses
>
> You want the number of hits to be significantly larger than the number
> of misses. And you want the number of hits to keep growing. Another
> thing to look at is "systat vm". If you mke your screen a bit bigger
> than 25 lines, you'll see a "pzidle" counter which indicates how much
> zeroed pages have been consumed (negative) or created (positive).
>
> Thanks,
>
> Mark
Forgot to include a file in the diff. Here is a complete one:
Index: kern/init_main.c
===
RCS file: /home/cvs/src/sys/kern/init_main.c,v
retrieving revision 1.217
diff -u -p -r1.217 init_main.c
--- kern/init_main.c14 Aug 2014 09:01:47 - 1.217
+++ kern/init_main.c2 Sep 2014 19:02:37 -
@@ -526,6 +526,10 @@ main(void *framep)
if (kthread_create(uvm_aiodone_daemon, NULL, NULL, "aiodoned"))
panic("fork aiodoned");
+ /* Create the page zeroing kernel thread. */
+ if (kthread_create(uvm_pagezero_thread, NULL, NULL, "zerothread"))
+ panic("fork zerothread");
+
#if defined(MULTIPROCESSOR)
/* Boot the secondary processors. */
cpu_boot_secondary_processors();
Index: uvm/uvm_extern.h
===
RCS file: /home/cvs/src/sys/uvm/uvm_extern.h,v
retrieving revision 1.119
diff -u -p -r1.119 uvm_extern.h
--- uvm/uvm_extern.h11 Jul 2014 16:35:40 - 1.119
+++ uvm/uvm_extern.h12 Jul 2014 19:02:23 -
@@ -519,6 +519,7 @@ voiduvm_vnp_sync(struct mount *);
void uvm_vnp_terminate(struct vnode *);
boolean_t uvm_vnp_uncache(struct vnode *);
struct uvm_object *uvn_attach(struct vnode *, vm_prot_t);
+void uvm_pagezero_thread(void *);
void kmeminit_nkmempages(void);
void kmeminit(void);
extern u_int nkmempages;
Index: uvm/uvm_page.h
===
RCS file: /home/cvs/src/sys/uvm/uvm_page.h,v
retrieving revision 1.54
diff -u -p -r1.54 uvm_page.h
--- uvm/uvm_page.h 11 Jul 2014 16:35:40 - 1.54
+++ uvm/uvm_page.h 12 Jul 2014 19:02:23 -
@@ -296,7 +296,7 @@ int vm_physseg_find(paddr_t, int *);
#define uvm_lock_fpageq() mtx_enter(&uvm.fpageqlock);
#define uvm_unlock_fpageq()mtx_leave(&uvm.fpageqlock);
-#defineUVM_PAGEZERO_TARGET (uvmexp.free)
+#defineUVM_PAGEZERO_TARGET (uvmexp.free / 8)
#define VM_PAGE_TO_PHYS(entry) ((entry)->phys_addr)
Index: uvm/uvm_pmemrange.c
===
RCS file: /home/cvs/src/sys/uvm/uvm_pmemrange.c,v
retrieving revision 1.41
diff -u -p -r1.41 uvm_pmemrange.c
--- uvm/uvm_pmemrange.c 14 Sep 2014 14:17:27 - 1.41
+++ uvm/uvm_pmemrange.c 24 Sep 2014 15:29:00 -
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
/*
@@ -107,7 +108,7 @@ voiduvm_pmr_assertvalid(struct uvm_pmem
#endif
int uvm_pmr_get1page(psize_t, int, struct pglist *,
- paddr_t, paddr_t);
+ paddr_t, paddr_t, int);
struct uvm_pmemrange *uvm_pmr_allocpmr(void);
struct vm_page *uvm_pmr_nfindsz(struct uvm_pmemrange *, psize_t, int);
@@ -824,7 +825,7 @@ retry_desperate:
if (count <= maxseg && align == 1 && boundary == 0 &&
(flags & UVM_PLA_TRYCONTIG) == 0) {
fcount += uvm_pmr_get1page(count - fcount, memtype_init,
- result, start, end);
+ result, start, end, 0);
/*
* If we found sufficient pages, go to the succes exit code.
@@ -1036,6 +1037,8 @@ out:
if (found->pg_flags & PG_ZERO) {
uvmexp.zeropages--;
+ if (uvmexp.zeropages < UVM_PA
Re: maketz.sh problems with distrib build
> On Sat, Sep 27, 2014 at 10:46 AM, wrote:
> > On Sat, 27 Sep 2014 09:02:52 +0300
> >> On Sat, Sep 27, 2014 at 7:10 AM, wrote:
> >> > i encounter this error when building the (RAMDISK_CD) distrib kernel:
> >> > usage: maketz.sh DESTDIR
> >> ...
> >> > maybe the method i have been using to build distrib is outdated.
> >> > currently i do:
> >> > # (cd /usr/src/distrib/special/libstubs && make)
> >> > # cd /usr/src/distrib/i386/ramdisk_cd && make
> >> > which i got some years ago from one of these lists. is this still the
> >> > preferred
> >> > method?
> >>
> >> I don't think that was ever correct. The procedure for building a
> >> release is documented in release(8).
> >>
> >> (Why does that procedure install into a clean directory and assemble
> >> the release out of that? To absolutely guarantee that it cannot pick
> >> up a file left over in the running install from a previous version.)
> >
> > i guess it isn't clear, but i was never trying to make the release, only the
> > kernel. i've reconfigured them for live cd's and such.
>
> You are building the ramdisk, which is part of the release. You may
> be able to skip some of the steps involved because you don't want the
> .tgz outputs, but if you want to use the scripts that OpenBSD provides
> for this then you need to follow the base steps, including setting
> DESTDIR and installing into that.
so DESTDIR is set by some earlier process, so my first suggestion was wrong
($DESTDIR -> ${TARGDIR}). but that's only what got me looking, and is
irrelevent to the issue of the use of 'maketz.sh'.
what i am concerned with there is when distrib/miniroot/list2sh.awk is run, to
create the bsd.rd miniroot 'var/tzlist', the relevant line in list2sh.awk is:
printf("(cd ${TARGDIR}; sh $UTILS/maketz.sh $DESTDIR)\n");
which calls maketz.sh:
#!/bin/sh
destdir=$1
if [ $# -lt 1 ]; then
echo usage: maketz.sh DESTDIR
exit 0
fi
(
cd $destdir/usr/share/zoneinfo
ls -1dF `tar cvf /dev/null [A-Za-y]*`
) > var/tzlist
however my questioning of 'maketz.sh' use is sound, and it can be bypassed
altogether in 'list2sh.awk':
printf("(cd $DESTDIR/usr/share/zoneinfo && ls -1dF `tar cvf /dev/null
[A-Za-y]*`) >var/tzlist");
as it stands, if $DESTDIR is unset it gives the error i first mentioned:
usage: maketz.sh DESTDIR
and no 'var/tzlist' is created, which presumably will not happen if i were
using it 'properly'.
with the change to 'list2sh.awk' above, if $DESTDIR is unset, then it merely
does the same thing as if $DESTDIR=/
so if $DESTDIR is unset, it does 'cd /usr/share/zoneinfo'.
and if $DESTDIR is set (to / as in release(8)) then it does
'cd //usr/share/zoneinfo'
and if there is no $DESTDIR/usr/share/zoneinfo, it doesn't create a file of
potentially random crap (the &&).
so, with the below patch, if $DESTDIR is set, is should function as it does
now, and 'maketz.sh' can be eliminated altogether. and if DESTDIR is unset,
it still works (presumably there will always be a /usr/share/zoneinfo on
any system building release)
--- list2sh.awk.origFri Feb 21 14:33:31 2014
+++ list2sh.awk Sat Sep 27 05:35:09 2014
@@ -60,7 +60,7 @@ $1 == "CRUNCHSPECIAL" {
}
$1 == "TZ" {
printf("echo '%s'\n", $0);
- printf("(cd ${TARGDIR}; sh $UTILS/maketz.sh $DESTDIR)\n");
+printf("(cd $DESTDIR/usr/share/zoneinfo && ls -1dF `tar cvf /dev/null
[A-Za-y]*` >${TARGDIR}/var/tzlist)");
next;
}
$1 == "COPYDIR" {
and i knew i was probably missing something, this was the reason for all the
question marks. i knew DESTDIR had to have been set if releases were to be
built at all. i was just questioning what the situation was, and now i know.
i didn't look at release(8) because i hadn't considered its relevance, thought
in retrospect should have. i just ran across this using a procedure i was
perhaps overly familiar with and forgot what it was a part of. but this is
sometimes how bugs are discovered and other improvements made, by using things
in ways that are not common, and looking at things not commonly looked at. the
common things get noticed.
and i wouldn't have said anything at all if i didn't think i had something
with 'maketz.sh'.
i know what i was doing was 'unsupported', and things could get broken, but it
hasn't failed me yet. i would've just ignored the maketz.sh error as i have
been.
so is there a better way to just build a kernel? i'm not going to build a
whole release just for one kernel, especially when experimenting. and i mean
a RAMDISK kernel. i think its great the things i can do with openbsd, even
when it is not what is intended.
> Is it worth your time to change those scripts locally (and maintain
> those changes as we evolve the scripts for *our* purposes) instead of
> just running them and then ignoring half the results? How much is
> your time worth?
are you saying i should just build the whole releas
Re: maketz.sh problems with distrib build
>so is there a better way to just build a kernel? i'm not going to build a >whole release just for one kernel, especially when experimenting. and i mean >a RAMDISK kernel. i think its great the things i can do with openbsd, even >when it is not what is intended. tough. I'm sorry, but this is the build process that makes snapshots. It serves that purpose and is designed for that. It is not carveable in the way you want to use it. It will not be changed. You are on your own, really.
Re: tplink TL-WN722N (ath ar9271): athn0: could not load firmware (and firmware is there)
On Thu, Sep 25, 2014 at 11:51 PM, Sébastien Marie wrote: > Hi, > > On Thu, Sep 25, 2014 at 06:18:11PM -0500, Abel Abraham Camarillo Ojeda wrote: >> I have this usb dongle: >> >> http://www.tp-link.com/en/products/details/?model=tl-wn722n#over >> >> Tplink TL-WN722N, which according to driver (*.inf) is an atheros ar9271 >> device. >> >> after inserting in usb slot I get: >> >> athn0 at uhub1 port 3 "ATHEROS USB2.0 WLAN" rev 2.00/1.08 addr 2 >> athn0: could not load firmware >> >> and nothing else happens, with it inserted I ran fw_update(1), and >> then tried to remove it and insert it again, still same message. >> >> should it work? > > it should. I have the same device, and it works here (-current, but it > works also in 5.5). You are right, it seems that this card don't works _on this machine_, I tried another OpenBSD/5.5/amd64-sp machine and it worked ok. >> $ ls -alsh /etc/firmware >> 140 -r--r--r-- 1 root bin 69.0K Jul 30 07:04 /etc/firmware/athn-ar7010 >> 140 -r--r--r-- 1 root bin 69.0K Jul 30 07:04 /etc/firmware/athn-ar7010-11 >> 104 -r--r--r-- 1 root bin 50.1K Jul 30 07:04 /etc/firmware/athn-ar9271 >> 8 -r--r--r-- 1 root bin 2.2K Jul 30 07:04 /etc/firmware/athn-license >> $ > > $ ls -alsh /etc/firmware/athn-* > 140 -r--r--r-- 1 root bin 69.0K Jan 11 2014 /etc/firmware/athn-ar7010 > 140 -r--r--r-- 1 root bin 69.0K Jan 11 2014 /etc/firmware/athn-ar7010-11 > 104 -r--r--r-- 1 root bin 50.1K Jan 11 2014 /etc/firmware/athn-ar9271 > 8 -r--r--r-- 1 root bin 2.2K Jan 11 2014 /etc/firmware/athn-license > > $ sha1 /etc/firmware/athn-* > SHA1 (/etc/firmware/athn-ar7010) = 4712a8674f6d32b3d2bb548d304177a0fea09558 > SHA1 (/etc/firmware/athn-ar7010-11) = 08d0587306e965cd7b04c0715114978395b5ac35 > SHA1 (/etc/firmware/athn-ar9271) = 494bc6957da8f6d04d68f8594337fee356c190d3 > SHA1 (/etc/firmware/athn-license) = 5fc3ee1bec135933fd8b1c73191e7d7556b9eed0 i have same files (same sha1) > $ pkg_info athn-firmware > Information for inst:athn-firmware-1.1p1 > [...] > > $ dmesg | grep athn > athn0 at uhub0 port 4 "ATHEROS USB2.0 WLAN" rev 2.00/1.08 addr 2 > athn0: AR9271 rev 1 (1T1R), ROM rev 13, address c0:4a:00:1c:c0:aa > > -- > Sébastien Marie I suspect this is an USB issue with this machine, will try to bisect to see if it works on an previous release. (i have had problems with usb on this machine): http://marc.info/?l=openbsd-cvs&m=139982602432291&w=2 Ideas? dmesg from working machine: OpenBSD 5.5 (GENERIC) #271: Wed Mar 5 09:31:16 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1048051712 (999MB) avail mem = 1011638272 (964MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf06b0 (42 entries) bios0: vendor American Megatrends Inc. version "0216" date 09/22/2009 bios0: ASUSTeK Computer INC. ITX-220 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P9(S4) P0P8(S4) P0P7(S4) P0P6(S4) P0P5(S4) P0P4(S4) PS2K(S4) PS2M(S4) UAR1(S4) USB2(S4) USB3(S4) USB4(S4) MC97(S4) USB1(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU 220 @ 1.20GHz, 1197.64 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu0: 512KB 64b/line 2-way L2 cache mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (P0P3) acpiprt3 at acpi0: bus -1 (P0P8) acpicpu0 at acpi0 aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x02 vga1 at pci0 dev 2 function 0 "Intel 82945G Video" rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 No connectors reported connected with modes Cannot find any crtc or sizes - going 1024x768 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi azalia0: codecs: VIA/0x4397 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01 pci1 at ppb0 bus 2 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x01: RTL8168 2 (0x3800), msi, address bc:ae:c5:78:22:a7 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 1 int 20 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 1 int 17 uhci2 at pci0 dev 29 fun
Re: tplink TL-WN722N (ath ar9271): athn0: could not load firmware (and firmware is there)
On Sat, Sep 27, 2014 at 4:42 AM, Abel Abraham Camarillo Ojeda wrote: > On Thu, Sep 25, 2014 at 11:51 PM, Sébastien Marie > wrote: >> Hi, >> >> On Thu, Sep 25, 2014 at 06:18:11PM -0500, Abel Abraham Camarillo Ojeda wrote: >>> I have this usb dongle: >>> >>> http://www.tp-link.com/en/products/details/?model=tl-wn722n#over >>> >>> Tplink TL-WN722N, which according to driver (*.inf) is an atheros ar9271 >>> device. >>> >>> after inserting in usb slot I get: >>> >>> athn0 at uhub1 port 3 "ATHEROS USB2.0 WLAN" rev 2.00/1.08 addr 2 >>> athn0: could not load firmware >>> >>> and nothing else happens, with it inserted I ran fw_update(1), and >>> then tried to remove it and insert it again, still same message. >>> >>> should it work? >> >> it should. I have the same device, and it works here (-current, but it >> works also in 5.5). > > > You are right, it seems that this card don't works _on this machine_, > I tried another OpenBSD/5.5/amd64-sp machine and it worked ok. I have tried: on non-working machine: OpenBSD-current/amd64.mp: not works OpenBSD-5.5/i386.mp: not works on working machine: OpenBSD-5.5/amd64.sp: works >>> $ ls -alsh /etc/firmware >>> 140 -r--r--r-- 1 root bin 69.0K Jul 30 07:04 /etc/firmware/athn-ar7010 >>> 140 -r--r--r-- 1 root bin 69.0K Jul 30 07:04 /etc/firmware/athn-ar7010-11 >>> 104 -r--r--r-- 1 root bin 50.1K Jul 30 07:04 /etc/firmware/athn-ar9271 >>> 8 -r--r--r-- 1 root bin 2.2K Jul 30 07:04 /etc/firmware/athn-license >>> $ >> >> $ ls -alsh /etc/firmware/athn-* >> 140 -r--r--r-- 1 root bin 69.0K Jan 11 2014 /etc/firmware/athn-ar7010 >> 140 -r--r--r-- 1 root bin 69.0K Jan 11 2014 /etc/firmware/athn-ar7010-11 >> 104 -r--r--r-- 1 root bin 50.1K Jan 11 2014 /etc/firmware/athn-ar9271 >> 8 -r--r--r-- 1 root bin 2.2K Jan 11 2014 /etc/firmware/athn-license >> >> $ sha1 /etc/firmware/athn-* >> SHA1 (/etc/firmware/athn-ar7010) = 4712a8674f6d32b3d2bb548d304177a0fea09558 >> SHA1 (/etc/firmware/athn-ar7010-11) = >> 08d0587306e965cd7b04c0715114978395b5ac35 >> SHA1 (/etc/firmware/athn-ar9271) = 494bc6957da8f6d04d68f8594337fee356c190d3 >> SHA1 (/etc/firmware/athn-license) = 5fc3ee1bec135933fd8b1c73191e7d7556b9eed0 > > i have same files (same sha1) > >> $ pkg_info athn-firmware >> Information for inst:athn-firmware-1.1p1 >> [...] >> >> $ dmesg | grep athn >> athn0 at uhub0 port 4 "ATHEROS USB2.0 WLAN" rev 2.00/1.08 addr 2 >> athn0: AR9271 rev 1 (1T1R), ROM rev 13, address c0:4a:00:1c:c0:aa >> >> -- >> Sébastien Marie > > I suspect this is an USB issue with this machine, will try to bisect > to see if it works on an previous release. (i have had problems with usb on > this machine): > > http://marc.info/?l=openbsd-cvs&m=139982602432291&w=2 > > Ideas? > > dmesg from working machine: > OpenBSD 5.5 (GENERIC) #271: Wed Mar 5 09:31:16 MST 2014 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 1048051712 (999MB) > avail mem = 1011638272 (964MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf06b0 (42 entries) > bios0: vendor American Megatrends Inc. version "0216" date 09/22/2009 > bios0: ASUSTeK Computer INC. ITX-220 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT FACP APIC MCFG OEMB HPET > acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P9(S4) P0P8(S4) P0P7(S4) > P0P6(S4) P0P5(S4) P0P4(S4) PS2K(S4) PS2M(S4) UAR1(S4) USB2(S4) > USB3(S4) USB4(S4) MC97(S4) USB1(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Celeron(R) CPU 220 @ 1.20GHz, 1197.64 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF > cpu0: 512KB 64b/line 2-way L2 cache > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 133MHz > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 addr 0xf000, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (P0P1) > acpiprt2 at acpi0: bus 1 (P0P3) > acpiprt3 at acpi0: bus -1 (P0P8) > acpicpu0 at acpi0 > aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM > acpibtn0 at acpi0: SLPB > acpibtn1 at acpi0: PWRB > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x02 > vga1 at pci0 dev 2 function 0 "Intel 82945G Video" rev 0x02 > intagp0 at vga1 > agp0 at intagp0: aperture at 0xd000, size 0x1000 > inteldrm0 at vga1 > drm0 at inteldrm0 > No connectors reported connected with modes > Cannot find any crtc or sizes - going 1024x768 > inteldrm0: 1024x768 > wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) > wsdisplay0: screen 1-5 added (std, vt100 emulation) > azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi > azalia0: codecs: VIA/0x4397 > audio0 at azalia0
Re: maketz.sh problems with distrib build
On Sat, 27 Sep 2014 03:38:30 -0600 (MDT)
> >so is there a better way to just build a kernel? i'm not going to build a
> >whole release just for one kernel, especially when experimenting. and i mean
> >a RAMDISK kernel. i think its great the things i can do with openbsd, even
> >when it is not what is intended.
>
> tough.
i wasn't whining, i was ASKING, and that was only an aside, not the main point
of my last message, which was an analysis of 'maketz.sh'.
this is only what got me looking at 'maketz.sh' and 'list2sh.awk'. my findings
there are relevant.
> I'm sorry, but this is the build process that makes snapshots.
> It serves that purpose and is designed for that.
did i ever say or suggest otherwise?
> It is not carveable in the way you want to use it.
obviously it is, even if 'unsupported'. i got the idea from a user on one of
the lists years ago, so it works for at least two people.
and that's still not relevant to what i said about 'maketz.sh'.
> It will not be changed.
i don't expect it to be changed for ME. my points about 'maketz.sh' are still
valid until someone show otherwise. THEY HAVE NOTHING TO DO WITH MY
'UNSUPPORTED' USE.
> You are on your own, really.
let me quote myself, the paragraph above what you quoted:
> > i know what i was doing was 'unsupported', and things could get broken, but
> > it
> > hasn't failed me yet. i would've just ignored the maketz.sh error as i have
> > been.
which by the way is irrelevant to the point i was making about 'maketz.sh'.
this 'unsupported use' is merely why i was poking around there.
and me again:
> > and once more, i ONLY brought this up because of maketz.sh looks irrelevent.
> > i have been using openbsd for more years than i can honestly remember, i
> > know
> > nobody here 'makes music for the fans'.
and to clarify 'nobody here makes music for the fans', means, to quote you:
> You are on your own, really.
so we are in complete agreement here.
and this is all irrelevant. someone address what i said about 'maketz.sh'.
the fix i made ONLY eliminates 'maketz.sh', not its functionality, which
is only *2 lines* and can be put in 'list2sh.awk' instead.
the fact that it allows my 'blasphemous' behaviour was also irrelevant, i
didn't care about that. i can just add 'DESTDIR=/' to my automated scripts
to make this kernel, no biggie. i don't NEED a change to the system, and
never asked for one for myself, to quote myself again:
> > and once more, i ONLY brought this up because of maketz.sh looks irrelevent.
now, did you read any of what i said about 'maketz.sh'? the proposed fix was to
eliminate it completely, placing its meager contents in 'list2sh.awk'.
i know you probably get dumb requests all the time, but maybe you shouldn't
jump to conclusions. i think i was pretty explicit, and if not, i would love
to know where i was ambiguous, to avoid it in the future.
back to 'maketz.sh':
simply, all 'maketz.sh' does is run:
cd $destdir/usr/share/zoneinfo
ls -1dF `tar cvf /dev/null [A-Za-y]*`
and this can be done in 'list2sh.awk' instead of said script calling 'maketz.sh'
was:
printf("(cd ${TARGDIR}; sh $UTILS/maketz.sh $DESTDIR)\n");
i proposed:
printf("(cd $DESTDIR/usr/share/zoneinfo && ls -1dF `tar cvf /dev/null
[A-Za-y]*` >${TARGDIR}/var/tzlist)\n");
for a measly two lines of script. the error check is irrelevant if used
properly because $DESTDIR should always be set, thus the arg check is useless,
it should always be true (if used 'THE RIGHT WAY') and that leave 2 lines of
code. does 'maketz.sh' need to exist for two lines of code that can be put in
'list2sh.awk'?
once again, that this fixed *MY* problem is irrelevant. i don't want your help.
i don't want anyone's help. never did. to quote myself again on this point:
> > and once more, i ONLY brought this up because of maketz.sh looks irrelevent.
i left $DESTDIR in the fix, since i now know it's relevant.
now here is what i said again, if there is a logical flaw in my argument, i
would love to hear it:
> > what i am concerned with there is when distrib/miniroot/list2sh.awk is run,
> > to
> > create the bsd.rd miniroot 'var/tzlist', the relevant line in list2sh.awk
> > is:
> >
> > printf("(cd ${TARGDIR}; sh $UTILS/maketz.sh $DESTDIR)\n");
> >
> > which calls maketz.sh:
> > #!/bin/sh
> >
> > destdir=$1
> >
> > if [ $# -lt 1 ]; then
> > echo usage: maketz.sh DESTDIR
> > exit 0
> > fi
> >
> > (
> > cd $destdir/usr/share/zoneinfo
> > ls -1dF `tar cvf /dev/null [A-Za-y]*`
> > ) > var/tzlist
> >
> > however my questioning of 'maketz.sh' use is sound, and it can be bypassed
> > altogether in 'list2sh.awk':
> >
> > printf("(cd $DESTDIR/usr/share/zoneinfo && ls -1dF `tar cvf
> > /dev/null [A
> >
> > as it stands, if $DESTDIR is unset it gives the error i first mentioned:
> >
> > usage: maketz.sh DESTDIR
> >
> > and no 'var/tzlist' is c
Re: maketz.sh problems with distrib build
i think this was sent to me personally by mistake (i had reply-to set). it
seems part of the conversation, and nothing seems confidential, so i am posting
my reply to tech@
especially as it is relevant to those who may want to know this later.
On Sat, 27 Sep 2014 05:13:42 -0600 (MDT)
> Your diff is wrong. the script exists to avoid the long wrapping line.
ok, but also in 'list2sh.awk' is:
printf("(cd ${TARGDIR}; tic -C -x -r -e %s
${UTILS}/../../share/termtypes/termtypes.master | sed -e '/^#.*/d' -e '/^$$/d'
> %s)\n",
wouldn't that have the same issue?
either way, this seems something worthy of a comment in 'maketz.sh'.
--- maketz.sh.orig Wed May 6 23:43:02 2009
+++ maketz.sh Sat Sep 27 08:26:14 2014
@@ -1,5 +1,7 @@
#!/bin/sh
+#this script exists to avoid the long wrapping line.
+
destdir=$1
if [ $# -lt 1 ]; then
[Patch] avoid typecast
Hi, there is no need for the typecast. fritjof Index: xmalloc.c === RCS file: /cvs/src/usr.bin/rcs/xmalloc.c,v retrieving revision 1.4 diff -u -p -r1.4 xmalloc.c --- xmalloc.c 7 Jun 2009 08:39:13 - 1.4 +++ xmalloc.c 20 Jun 2014 10:21:37 - @@ -32,8 +32,8 @@ xmalloc(size_t size) ptr = malloc(size); if (ptr == NULL) errx(1, - "xmalloc: out of memory (allocating %lu bytes)", - (u_long) size); + "xmalloc: out of memory (allocating %zu bytes)", + size); return ptr; } @@ -48,8 +48,8 @@ xcalloc(size_t nmemb, size_t size) errx(1, "xcalloc: nmemb * size > SIZE_MAX"); ptr = calloc(nmemb, size); if (ptr == NULL) - errx(1, "xcalloc: out of memory (allocating %lu bytes)", - (u_long)(size * nmemb)); + errx(1, "xcalloc: out of memory (allocating %zu bytes)", + (size * nmemb)); return ptr; } @@ -68,8 +68,8 @@ xrealloc(void *ptr, size_t nmemb, size_t else new_ptr = realloc(ptr, new_size); if (new_ptr == NULL) - errx(1, "xrealloc: out of memory (new_size %lu bytes)", - (u_long) new_size); + errx(1, "xrealloc: out of memory (new_size %zu bytes)", + new_size); return new_ptr; }
Re: [Patch]openrcs: atoi to strtonum
On Fri, Sep 26, 2014 at 09:23:08PM +0200, Fritjof Bornebusch wrote:
> On Wed, Sep 24, 2014 at 10:31:17PM +0200, Otto Moerbeek wrote:
> Hi,
>
> > On Wed, Sep 24, 2014 at 05:13:47PM +0200, Fritjof Bornebusch wrote:
> >
> > > Hi,
> > >
> > > I changed atoi to strtonum in order to avoid overflows.
> >
> > One concern: atoi() does not mind trailing stuff, while strtonum()
> > does. Did you verify that the strings are just numbers in all cases?
> >
>
> according to the code and the manpages there are two different methods
> available to specify the timezone.
>
> - "LT"
> - +-hh:mm
>
> "LT" is handled seperatly and the code below - atoi(3) - only converts the
> hour and
> minute string values after seperation into int, e.g. "+09:88" -> h = 09; m =
> 88.
> The + or - sign will be handled in a different part of the code.
>
> I think this diff won't change functionality.
OK, that looks good. Anybody else wnat to ok this so I can commit?
>
>
> > -Otto
> >
>
> fritjof
>
> > >
> > > fritjof
> > >
> > >
> > >
> > > Index: rcstime.c
> > > ===
> > > RCS file: /cvs/src/usr.bin/rcs/rcstime.c,v
> > > retrieving revision 1.4
> > > diff -u -p -r1.4 rcstime.c
> > > --- rcstime.c 29 Apr 2014 07:44:19 - 1.4
> > > +++ rcstime.c 24 Sep 2014 15:06:42 -
> > > @@ -36,6 +36,7 @@ rcs_set_tz(char *tz, struct rcs_delta *r
> > > int tzone;
> > > int pos;
> > > char *h, *m;
> > > + const char *errstr;
> > > struct tm *ltb;
> > > time_t now;
> > >
> > > @@ -62,8 +63,8 @@ rcs_set_tz(char *tz, struct rcs_delta *r
> > >
> > > memcpy(tb, &rdp->rd_date, sizeof(*tb));
> > >
> > > - tzone = atoi(h);
> > > - if ((tzone >= 24) || (tzone <= -24))
> > > + tzone = strtonum(h, -23, 23, &errstr);
> > > + if (errstr)
> > > errx(1, "%s: not a known time zone", tz);
> > >
> > > if (pos) {
> > > @@ -78,9 +79,9 @@ rcs_set_tz(char *tz, struct rcs_delta *r
> > > tb->tm_hour = 0;
> > >
> > > if (m != NULL) {
> > > - tzone = atoi(m);
> > > - if (tzone >= 60)
> > > - errx(1, "%s: not a known time zone", tz);
> > > + tzone = strtonum(m, 0, 59, &errstr);
> > > + if (errstr)
> > > + errx(1, "%s: not a known minute", m);
> > >
> > > if ((tb->tm_min + tzone) >= 60) {
> > > tb->tm_hour++;
Re: [Patch] avoid typecast
On Sat, Sep 27, 2014 at 03:48:54PM +0200, Fritjof Bornebusch wrote: > Hi, > > there is no need for the typecast. Committed, thanks, -Otto > > fritjof > > > Index: xmalloc.c > === > RCS file: /cvs/src/usr.bin/rcs/xmalloc.c,v > retrieving revision 1.4 > diff -u -p -r1.4 xmalloc.c > --- xmalloc.c 7 Jun 2009 08:39:13 - 1.4 > +++ xmalloc.c 20 Jun 2014 10:21:37 - > @@ -32,8 +32,8 @@ xmalloc(size_t size) > ptr = malloc(size); > if (ptr == NULL) > errx(1, > - "xmalloc: out of memory (allocating %lu bytes)", > - (u_long) size); > + "xmalloc: out of memory (allocating %zu bytes)", > + size); > return ptr; > } > > @@ -48,8 +48,8 @@ xcalloc(size_t nmemb, size_t size) > errx(1, "xcalloc: nmemb * size > SIZE_MAX"); > ptr = calloc(nmemb, size); > if (ptr == NULL) > - errx(1, "xcalloc: out of memory (allocating %lu bytes)", > - (u_long)(size * nmemb)); > + errx(1, "xcalloc: out of memory (allocating %zu bytes)", > + (size * nmemb)); > return ptr; > } > > @@ -68,8 +68,8 @@ xrealloc(void *ptr, size_t nmemb, size_t > else > new_ptr = realloc(ptr, new_size); > if (new_ptr == NULL) > - errx(1, "xrealloc: out of memory (new_size %lu bytes)", > - (u_long) new_size); > + errx(1, "xrealloc: out of memory (new_size %zu bytes)", > + new_size); > return new_ptr; > } >
[Patch] use exit() directly in usage()
Hi,
after usage() was called, there is no where you can go.
fritjof
Index: ci.c
===
RCS file: /cvs/src/usr.bin/rcs/ci.c,v
retrieving revision 1.217
diff -u -p -r1.217 ci.c
--- ci.c19 May 2014 19:42:24 - 1.217
+++ ci.c2 Jun 2014 22:18:25 -
@@ -97,6 +97,8 @@ checkin_usage(void)
" [-j[rev]] [-k[rev]] [-l[rev]] [-M[rev]] [-mmsg]\n"
" [-Nsymbol] [-nsymbol] [-r[rev]] [-sstate] [-t[str]]\n"
" [-u[rev]] [-wusername] [-xsuffixes] [-ztz] file ...\n");
+
+ exit(1);
}
/*
@@ -221,7 +223,6 @@ checkin_main(int argc, char **argv)
break;
default:
(usage)();
- exit(1);
}
}
@@ -231,7 +232,6 @@ checkin_main(int argc, char **argv)
if (argc == 0) {
warnx("no input file");
(usage)();
- exit(1);
}
if ((pb.username = getlogin()) == NULL)
Index: co.c
===
RCS file: /cvs/src/usr.bin/rcs/co.c,v
retrieving revision 1.117
diff -u -p -r1.117 co.c
--- co.c16 Apr 2013 20:24:45 - 1.117
+++ co.c2 Jun 2014 22:19:38 -
@@ -79,7 +79,6 @@ checkout_main(int argc, char **argv)
if (RCS_KWEXP_INVAL(kflag)) {
warnx("invalid RCS keyword substitution mode");
(usage)();
- exit(1);
}
break;
case 'l':
@@ -141,7 +140,6 @@ checkout_main(int argc, char **argv)
break;
default:
(usage)();
- exit(1);
}
}
@@ -151,7 +149,6 @@ checkout_main(int argc, char **argv)
if (argc == 0) {
warnx("no input file");
(usage)();
- exit (1);
}
if ((username = getlogin()) == NULL)
@@ -229,6 +226,8 @@ checkout_usage(void)
"usage: co [-TV] [-ddate] [-f[rev]] [-I[rev]] [-kmode] [-l[rev]]\n"
" [-M[rev]] [-p[rev]] [-q[rev]] [-r[rev]] [-sstate]\n"
" [-u[rev]] [-w[user]] [-xsuffixes] [-ztz] file ...\n");
+
+ exit(1);
}
/*
Index: merge.c
===
RCS file: /cvs/src/usr.bin/rcs/merge.c,v
retrieving revision 1.7
diff -u -p -r1.7 merge.c
--- merge.c 23 Jul 2010 21:46:05 - 1.7
+++ merge.c 2 Jun 2014 22:20:55 -
@@ -77,7 +77,6 @@ merge_main(int argc, char **argv)
exit(0);
default:
(usage)();
- exit(D_ERROR);
}
}
argc -= optind;
@@ -86,7 +85,6 @@ merge_main(int argc, char **argv)
if (argc != 3) {
warnx("%s arguments", (argc < 3) ? "not enough" : "too many");
(usage)();
- exit(D_ERROR);
}
for (; labels < 3; labels++)
@@ -118,4 +116,6 @@ merge_usage(void)
{
(void)fprintf(stderr,
"usage: merge [-EepqV] [-L label] file1 file2 file3\n");
+
+ exit(D_ERROR);
}
Index: rcsclean.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsclean.c,v
retrieving revision 1.52
diff -u -p -r1.52 rcsclean.c
--- rcsclean.c 28 Jul 2010 09:07:11 - 1.52
+++ rcsclean.c 2 Jun 2014 22:22:05 -
@@ -60,7 +60,6 @@ rcsclean_main(int argc, char **argv)
if (RCS_KWEXP_INVAL(kflag)) {
warnx("invalid RCS keyword substitution mode");
(usage)();
- exit(1);
}
break;
case 'n':
@@ -90,7 +89,6 @@ rcsclean_main(int argc, char **argv)
break;
default:
(usage)();
- exit(1);
}
}
@@ -104,7 +102,6 @@ rcsclean_main(int argc, char **argv)
if ((dirp = opendir(".")) == NULL) {
warn("opendir");
(usage)();
- exit(1);
}
while ((dp = readdir(dirp)) != NULL) {
@@ -127,6 +124,8 @@ rcsclean_usage(void)
fprintf(stderr,
"usage: rcsclean [-TV] [-kmode] [-n[rev]] [-q[rev]] [-r[rev]]\n"
"[-u[rev]] [-xsuffixes] [-ztz] [file ...]\n");
+
+ exit(1);
}
static void
Index: rcsdiff.c
===
RCS file: /cvs/src/usr.bin/rcs/rcsdiff.c,v
retrieving revision 1.79
diff -u -p -r1.79 rcsdiff.c
--- rcsdiff.c 16 Apr 2013 20:24:45 - 1
