Re: diff: get rid the "out of static map entries" problem
2011/4/18 Ted Unangst :
> +if (uvm.numof_free_kentries < 1) /*check to be safe*/
> +panic("uvm.numof_free_kentries[%d] < 1\n",
uvm.numof_free_kentries);
>>> This diff would take us back to the bad old days when running out of
entries led
>>> to a panic.
>> Totally conversely. As It was showed above, that situation completely
>> resolved and not fatal.
>> Other panics I add just for debug and to be safe that algorithm works
>> correctly. If all work correctly these panics does not appear even in
>> bad situation (kernel_map exhausted).
>
> I believe the above panic will occur whenever there is no free entry,
> which will happen after the last "reserve" entry is used. If trying
> to get more fails (most likely because the map is full), then we'll
> use the reserve and the next allocation will fail.
If you recheck the diff carefully you will see that it is not (at
least, it must not, if all goes right).
First, if (uvm.numof_free_kentries == 1) then my code tries to
allocate page, divide it to new kentries and add them to
uvm.kentry_free.
It will be done only if uvm_km_kmemalloc(kentry_map,...) succeeds. And
only if this uvm_km_kmemalloc(kentry_map,...) succeeds, it will use
last reserved kentry
+ if (map == kentry_map) {
...
+ uvm.kentry_free = me->next;
+ uvm.numof_free_kentries--;
+ uvmexp.kmapent++;
+ me->flags = UVM_MAP_STATIC;
+ } else
But if uvm_km_kmemalloc(kentry_map,...) fails, it will unmap region it
mapped (check code in uvm_km_kmemalloc,
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/uvm/uvm_km.c?annotate=1.96,
line 380: and 424:).
And during this unmap it RETURN BACK (by uvm_mapent_free()) that last
reserved kentry it may use.
So if it fails, yes, we can't make new kentries. But reserved kentry
restored, it still here. And we are safe and ready to try again later.
Anyhow, even if uvm_km_kmemalloc(kentry_map,...) fails (either if
kentry_map is full or uvm_pglistalloc failed to get free page), then
when memory pressure goes down new allocations will succeed. Nothing
fatal.
That is the principle - fully predictable states, as it must be.
> fail, but it is unlikely. My laptop prints the warning message about
> running out of static entries quite frequently, but never fails to get
> a new page.
When my server show some "reasonable amount" ot these "out of static
entries" then I know it's time to go and reboot it. If not, then,
sooner or later, I'll see frozen machine (at very wrong time,
usually).
> An allocation failing when a map is out of space is not
> just likely, it's a certainty.
Of course. But it is completely predictable, not fatal (if we talk
about kernel stability).
By the way, we can setup the kentry_map size based on total memory
size, calculated when memory subsystem bootstrap. Either we can set it
rather big and be sure it is enough to allocate all physical memory,
or we can save more or less VA space with more or less risk that
kentry_map will be full. That's it, we must choose, since we
!HAVE_PMAP_DIRECT.
And we are talking about kernel memory allocations, yes? It's all
related to maps with VM_MAP_INTRSAFE flag.
> I don't think the kmthread mechanism is perfect, but it's fairly well
> understood and does not cause problems that I'm aware of. Are you
> actually experiencing a problem where uvm_km_getpage is failing?
Maybe. But these "out of static entries" is proved signal, that kernel
corrupted somehow.
Furthermore, what state of the kernel will be if all free kmthread's
pages will be used and all static ketries will be used (and so the
uvm.kentry_free is NULL)? Or some other "interesting situation"?
Something will try to allocate memory and (because of unpredictable
nature of that mechanism) then the kernel may locks itself.
> a real problem. In general, I don't like any change that introduces a
> new magic map or fixed limit. We suffered for years from various
> subsystems reserving KVA that they didn't need (and other systems
> failing when they ran out).
I strongly tried to avoid this. Yes, "brand new map" seems not so
pretty. But remember, these kentries is fundamental for all uvm system
to work as expected. So why the "malloc" is allowed use it's own map,
while "uvm" itself can't? I think that the situation with these
kentries was not clear when UVM was constructed and that is why the
ketries mechanism was not well designed.
And remember, I present this kentry_map when art@ says something like
"it's bad to use kmem_map", so there were no other way...
Anyhow, I understand that it is bad when some static values of KVA
reserved. But I showed the problem, showed the way to the solution.
Simple, easy to understand the idea.
If you stand against of "new brand kentry_map", but agreed with the
idea itself, I think there may be other ways to achieve same result
without new map but with same "finite state machine" approach.
Of course, it will be (much more?) tricky, but I believe it's poss
make ahci reserve a ccb for error recovery
since atascsi screws it up...
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.174
diff -u -p -r1.174 ahci.c
--- ahci.c 7 Apr 2011 15:30:16 - 1.174
+++ ahci.c 18 Apr 2011 01:39:19 -
@@ -373,6 +373,7 @@ struct ahci_port {
TAILQ_HEAD(, ahci_ccb) ap_ccb_free;
TAILQ_HEAD(, ahci_ccb) ap_ccb_pending;
struct mutexap_ccb_mtx;
+ struct ahci_ccb *ap_ccb_err;
u_int32_t ap_state;
#define AP_S_NORMAL0
@@ -863,8 +864,7 @@ noccc:
aaa.aaa_methods = &ahci_atascsi_methods;
aaa.aaa_minphys = NULL;
aaa.aaa_nports = AHCI_MAX_PORTS;
- aaa.aaa_ncmds = sc->sc_ncmds;
- aaa.aaa_capability = ASAA_CAP_NEEDS_RESERVED;
+ aaa.aaa_ncmds = sc->sc_ncmds - 1;
if (!(sc->sc_flags & AHCI_F_NO_NCQ) &&
(sc->sc_cap & AHCI_REG_CAP_SNCQ)) {
aaa.aaa_capability |= ASAA_CAP_NCQ | ASAA_CAP_PMP_NCQ;
@@ -1292,6 +1292,10 @@ nomem:
ahci_enable_interrupts(ap);
+ /* grab a ccb for use during error recovery */
+ ap->ap_ccb_err = &ap->ap_ccbs[sc->sc_ncmds - 1];
+ TAILQ_REMOVE(&ap->ap_ccb_free, ap->ap_ccb_err, ccb_entry);
+
freeport:
if (rc != 0)
ahci_port_free(sc, port);
@@ -1313,6 +1317,9 @@ ahci_port_free(struct ahci_softc *sc, u_
ahci_write(sc, AHCI_REG_IS, 1 << port);
}
+ if (ap->ap_ccb_err)
+ ahci_put_ccb(ap->ap_ccb_err);
+
if (ap->ap_ccbs) {
while ((ccb = ahci_get_ccb(ap)) != NULL)
bus_dmamap_destroy(sc->sc_dmat, ccb->ccb_dmamap);
@@ -3012,12 +3019,11 @@ ahci_get_err_ccb(struct ahci_port *ap)
* Grab a CCB to use for error recovery. This should never fail, as
* we ask atascsi to reserve one for us at init time.
*/
- err_ccb = ahci_get_ccb(ap);
- KASSERT(err_ccb != NULL);
+ err_ccb = ap->ap_ccb_err;
err_ccb->ccb_xa.flags = 0;
err_ccb->ccb_done = ahci_empty_done;
- return err_ccb;
+ return (err_ccb);
}
void
@@ -3037,8 +3043,10 @@ ahci_put_err_ccb(struct ahci_ccb *ccb)
printf("ahci_port_err_ccb_restore but SACT %08x != 0?\n", sact);
KASSERT(ahci_pread(ap, AHCI_PREG_CI) == 0);
+#ifdef DIAGNOSTIC
/* Done with the CCB */
- ahci_put_ccb(ccb);
+ KASSERT(ccb == ap->ap_ccb_err);
+#endif
/* Restore outstanding command state */
ap->ap_sactive = ap->ap_err_saved_sactive;
Re: usermod and -G option patch
On Sun, Apr 17, 2011 at 2:52 PM, Steve Clarke wrote: > I've modified the user.c and changed the append_group function to become the > modify_group function, and in the function, changed the code to remove the > user from the given groups (and append him as before if he is supposed to be > there). Someone beat you to the punch, but the general consensus is that changing the behavior of -G is not allowed. http://marc.info/?t=13022855112&r=1&w=2
Re: wol for xl(4)
On Sun, Apr 17, 2011 at 11:05:38AM +0200, Stefan Sperling wrote:
> On Thu, Mar 31, 2011 at 06:54:44PM +0200, Stefan Sperling wrote:
> > This is an attempt to add wol support to xl(4).
> >
> > Unfortunately, while I have an xl(4) card to test with none of the
> > motherboards I have will do WOL with it since they all lack an
> > on-board WOL connector :(
> >
> > So test reports are needed.
> > Please also check whether WOL is disabled by default.
>
> I haven't received any test reports yet.
The (commited) diff has no effect on my onboard xl(4).
The hardware supports this (BIOS setting checked):
http://support.dell.com/support/edocs/systems/dvol/en/vol_mt/SETUP.HTM#Wakeup
%20On%20LAN
OpenBSD 4.9-current (GENERIC.MP) #0: Mon Apr 18 02:39:32 CEST 2011
tobi...@boron.tmux.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) 499 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,
SSE
real mem = 2147049472 (2047MB)
avail mem = 2101751808 (2004MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 01/11/02, BIOS32 rev. 0 @ 0xffe90,
SMBIOS rev. 2.2 @ 0xfb1b0 (83 entries)
bios0: vendor Dell Computer Corporation version "A11" date 01/11/02
bios0: Dell Computer Corporation Precision WorkStation 610 MT
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices PCI0(S5) USB0(S5) PCI1(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0: invalid, skipping
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PCI1)
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) 499 MHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,
SSE
mpbios0: bus 0 is type PCI
mpbios0: bus 1 is type PCI
mpbios0: bus 2 is type PCI
mpbios0: bus 3 is type ISA
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
bios0: ROM list: 0xc/0xc000 0xcc000/0x9800 0xd5800/0x800 0xd6000/0x2000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82440BX AGP" rev 0x00
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xf000, size 0x400
ppb0 at pci0 dev 1 function 0 "Intel 82440BX AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "Trident Blade 3D" rev 0x3a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
piixpcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 152626MB, 312579695 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1 at pciide0 channel 1 drive 0:
wd1: 16-sector PIO, LBA48, 114473MB, 234441648 sectors
wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: apic 2 int 19
(irq 11)
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02: SMI
iic0 at piixpm0
admtemp0 at iic0 addr 0x2b: adm1021
iic0: addr 0x2d 06=40 09=50 14=53 1a=02 20=cf 21=bd 22=b9 23=7c 24=7d 25=bb
26=3b 27=1d 28=ff 29=50 2a=ff 2b=db 2c=c2 2d=d0 2e=a7 2f=d0 30=a7 31=83 32=77
33=83 34=77 35=c9 36=ae 37=70 38=12 39=4b 3a=46 3b=9a 3c=fa 3d=40 40=03 41=40
42=08 43=50 44=b8 46=40 47=f1 48=2d 49=c0 4a=fa 4b=c0 4c=c0 4d=c0 50=03 53=50
54=b8 56=40 57=f1 58=2d 59=c0 5a=c0 5b=c0 5c=c0 5d=c0 5e=c0 60=cf 61=bd 62=b9
63=7c 64=7d 65=bb 66=3b 67=1d 68=ff 69=50 6a=ff 6b=db 6c=c2 6d=d0 6e=a7 6f=d0
70=a7 71=83 72=77 73=83 74=77 75=c9 76=ae 77=70 78=12 79=4b 7a=46 7b=9a 7c=fa
7d=40 86=40 89=50 94=53 9a=02 a0=cf a1=bd a2=b9 a3=7c a4=7d a5=bb a6=3b a7=1d
a8=ff a9=50 aa=ff ab=db ac=c2 ad=d0 ae=a7 af=d0 b0=a7 b1=83 b2=77 b3=83 b4=77
b5=c9 b6=ae b7=70 b8=12 b9=4b ba=46 bb=9a bc=fa bd=40 c0=03 c3=50 c4=b8 c6=40
c7=f1 c8=2d c9=c0 ca=c0 cb=c0 cc=c0 cd=c0 ce=c0 d0=03 d3=50 d4=b8 d6=40 d7=f1
d8=2d d9=c0 da=c0 db=c0 dc=c0 dd=c0 de=c0 e0=cf e1=bd e2=b9 e3=7c e4=7d e5=bb
e6=3b e7=1d e8=ff e9=50 ea=ff eb=db ec=c2 ed=d0 ee=a7 ef=d0 f0=a7 f1=83 f2=77
f3=83 f4=77 f5=c9 f6=ae f7=70 f8=12 f9=4b fa=46 fb=9a fc=fa fd=40 words
00=0080 01=0080 02=0080 03=0080 04=0080 05=0080 06=4080 07=0080
admtemp1 at iic0 addr 0x4e: adm1021
spdmem0 at iic0 addr 0x50: 512MB SDRAM non-parity PC133CL3
spdmem1 at iic0 addr 0x51: 512MB SDRAM non-parity PC133CL3
spdmem2 at iic0 addr 0x52: 512MB SDRAM non-parity PC133CL3
spdmem3 at iic0 addr 0x53: 512MB SDRAM non-parity PC133CL3
xl0 at pci0 dev 13 function 0 "3Com 3c905C 100Base-TX" rev 0x78: apic 2 int 16
(irq 10), address 00:04:75:b1:00:7d
exphy0 at xl0 phy 24: 3Com internal media interface
rl0 at pci0 dev 14 function 0 "Realtek 8139" rev 0x10:
Re: diff: get rid the "out of static map entries" problem
On Sun, Apr 17, 2011 at 12:49 AM, Anton Maksimenkov
wrote:
+if (uvm.numof_free_kentries < 1) /*check to be safe*/
+panic("uvm.numof_free_kentries[%d] < 1\n", uvm.numof_free_kentries);
>> This diff would take us back to the bad old days when running out of
entries led
>> to a panic.
>
> Totally conversely. As It was showed above, that situation completely
> resolved and not fatal.
> Other panics I add just for debug and to be safe that algorithm works
> correctly. If all work correctly these panics does not appear even in
> bad situation (kernel_map exhausted).
I believe the above panic will occur whenever there is no free entry,
which will happen after the last "reserve" entry is used. If trying
to get more fails (most likely because the map is full), then we'll
use the reserve and the next allocation will fail. uvm_km_getpage can
fail, but it is unlikely. My laptop prints the warning message about
running out of static entries quite frequently, but never fails to get
a new page. An allocation failing when a map is out of space is not
just likely, it's a certainty.
I don't think the kmthread mechanism is perfect, but it's fairly well
understood and does not cause problems that I'm aware of. Are you
actually experiencing a problem where uvm_km_getpage is failing? That
is a theoretical concern, but I haven't seen evidence to suggest it's
a real problem. In general, I don't like any change that introduces a
new magic map or fixed limit. We suffered for years from various
subsystems reserving KVA that they didn't need (and other systems
failing when they ran out).
Re: fenv.h support for libm
I only see one remaining namespace glitch:
On Sun, Apr 17, 2011 at 4:11 AM, Martynas Venckus
wrote:
...
> +/*
> + * fenv_t represents the entire floating-point environment
> + */
> +typedef struct {
> + struct {
> + unsigned int __control; /* Control word register */
> + unsigned int __status; /* Status word register */
> + unsigned int __tag; /* Tag word register */
> + unsigned int __others[4]; /* EIP, Pointer Selector,
etc */
> + } x87;
> + unsigned int __mxcsr; /* Control, status register
*/
> +} fenv_t;
The 'x87' member should be something like '__x87', with the matching
tweak to feclearexcept(), fesetexceptflag(), fegetenv(), fesetenv(),
and feupdateenv().
I haven't worked through all the bit-twiddling and asm, but what I
have looks good and the abundance of regress tests that keep showing
up in "cvs up -d" inspires confidence. With that x87-->__x87 nit, ok
guenther@
Philip Guenther
Re: isprint() needs setlocale(); for usr.bin
On Sun, Apr 17, 2011 at 1:56 AM, Stefan Sperling wrote: > On Tue, Apr 05, 2011 at 12:25:37AM +0200, Stefan Sperling wrote: >> For isprint() to work correctly in a UTF-8 locale applications must >> set up the LC_CTYPE locale before using isprint(). >> >> As done for hexdump and tcpdump already. >> >> This diff covers all offenders in usr.bin. > > Todd Miller suggested using LC_ALL instead of LC_CTYPE so we don't have > to revisit these when we add support for more categories. Has there been any sort of audit of how this will affect scripts distributed with the system? I seem to recall having to fix various scripts elsewhere when Redhat started shipping with LANG=en_US.UTF-8 set in the default shell environment, things like character ranges in grep patterns changing behavior. The scripts didn't handle any sort of non-C locale correctly; the change in default just made that incredibly obvious. The quick fix is to apply the hammer and pass LC_ALL=C, but that's overkill when all you really want is to force LC_CTYPE=C behavior. Hmm... export LC_CTYPE=C [[ -n $LC_ALL ]] && export LC_COLLATE=$LC_ALL LC_TIME=$LC_ALL \ LC_NUMERIC=$LC_ALL LC_MONETARY=$LC_ALL LC_MESSAGES=$LC_ALL A quick grep of /etc/*/* on a Redhat box finds *lots* of LANG=C settings on commands. Wheee Philip Guenther
Re: wprintf and friends
On Sun, Apr 17, 2011 at 11:06:09AM +0100, Stuart Henderson wrote: > What's the current status of this diff? I have received no negative comments, but no explicit OKs either. My plan is to fix the wxWidgets and minicom ports before this goes in because they fail to build with it. I haven't found time yet. If anyone wants to take a shot at it, please go ahead. Note that the libstdc++ diff at http://marc.info/?l=openbsd-tech&m=130125983221605&w=2 is also needed to get some ports to compile (devel/boost and anything that depends on it). So these diffs need to go in together. And we'll need to bump both libc and libstdc++.
Re: disklabel -F|-f should print swap partitions too.
On Sun, Apr 17, 2011 at 12:34:54PM -0400, Kenneth R Westerback wrote: > > I am uncomfortable with removing the swapctl verbiasge, but I think it is much > more digestable if broken up and distributed as below. I moved the swap > lines in the example to the top, where they are likely to have been put > by the install process. Keeping sd0b seems better to me, but marginally so. > > Ken > broadly speaking, i'm ok with your diff. there's a couple tweaks i think we can make though - i'll detail them inline. > Index: sbin/swapctl/swapctl.8 > === > RCS file: /cvs/src/sbin/swapctl/swapctl.8,v > retrieving revision 1.30 > diff -u -p -r1.30 swapctl.8 > --- sbin/swapctl/swapctl.83 Sep 2010 10:08:22 - 1.30 > +++ sbin/swapctl/swapctl.817 Apr 2011 16:29:18 - > @@ -72,20 +72,6 @@ in which case > it acts as > .Ic swapctl -A . > .Pp > -.Sy Note : > -The initial swap device (root disk, partition b) is handled automatically > -by the kernel and does > -.Em not > -need to be added to > -.Pa /etc/fstab > -or added via > -.Nm swapctl . > -It will show up as > -.Qq swap_device > -in the output displayed with the > -.Fl l > -flag. > -.Pp > The options are as follows: > .Bl -tag -width Ds > .It Fl A > @@ -136,6 +122,8 @@ option uses 1024 byte blocks instead of > The > .Fl l > option lists the current swap devices and files, and their usage statistics. > +The initial swap device (root disk, partition b) will show up as > +.Qq swap_device . > .It Fl p Ar priority > The > .Fl p > @@ -168,13 +156,16 @@ may be needed before all file systems ar > disk checks of large file systems. > .El > .Sh SWAP OPTIONS > -When parsing the > .Pa /etc/fstab > -file for swap devices, lines such as the following specify additional swap > -devices: > +lines such as the following specify swap devices: i dislike starting this text as "/etc/fstab lines". i'd prefer something like "The following lines in /etc/fstab...". > .Bd -literal -offset indent > -/dev/sd1b none swap sw 0 0 > +/dev/sd1b none swap sw > +d48d0e3fc1c39531.k none swap sw > .Ed > +.Pp > +The initial swap device (root disk, partition b) does not need to appear in > +.Pa /etc/fstab , > +although it can. ...and i'd prefer "may" to "can". anything can appear in fstab, but only certain things may. except for these niggles, it's ok with me. jmc > .Pp > Additional flags include: > .Pp > Index: share/man/man5/fstab.5 > === > RCS file: /cvs/src/share/man/man5/fstab.5,v > retrieving revision 1.44 > diff -u -p -r1.44 fstab.5 > --- share/man/man5/fstab.528 Sep 2010 17:37:20 - 1.44 > +++ share/man/man5/fstab.517 Apr 2011 16:29:18 - > @@ -276,6 +276,8 @@ Here is a sample > .Pa /etc/fstab > file: > .Bd -literal -offset indent > +/dev/sd0b none swap sw > +/dev/sd1b none swap sw > /dev/sd0a / ffs rw 1 1 > /dev/sd0e /var ffs rw,nodev,nosuid 1 2 > #/dev/sd0f /tmp ffs rw,nodev,nosuid 1 2 > @@ -284,7 +286,6 @@ swap /tmp mfs rw,nodev,nosuid,-s=153600 > /dev/sd0h /usr/local ffs rw,nodev 1 2 > /dev/sd0i /home ffs rw,nodev,nosuid 1 2 > /dev/sd0j /usr/src ffs rw,nodev,nosuid,softdep 1 2 > -/dev/sd1b none swap sw 0 0 > /dev/cd0a /cdrom cd9660 ro,noauto 0 0 > 5b27c2761a9b0b06.i /mnt/key msdos rw,noauto 0 0 > server:/export/ports /usr/ports nfs rw,nodev,nosuid,soft,intr 0 0
usermod and -G option patch
As posted to the openbsd forum in March, the usermod program only appends
users to secondary groups with the -G switch, rather than setting the
secondary groups.
As mentioned previously, this problem has been around for some 10 years.
http://marc.info/?l=openbsd-misc&m=109088617022480&w=2
http://marc.info/?l=tru64-unix-managers&m=97203990632722&w=2
I've modified the user.c and changed the append_group function to become the
modify_group function, and in the function, changed the code to remove the
user from the given groups (and append him as before if he is supposed to be
there).
To append a user to a group, you would now do something like:
$groups=`groups $user | sed -e 's/ /,/'`
usermod -G $groups,newgroup $user
Diff appears below:
Steve Clarke
Index: user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.81
diff -u -r1.81 user.c
--- user.c 16 Apr 2011 07:41:08 - 1.81
+++ user.c 17 Apr 2011 18:35:26 -
@@ -485,9 +485,9 @@
return 1;
}
-/* modify the group entries for all `groups', by adding `user' */
+/* modify the group entries for all `groups', by adding or removing `user' */
static int
-append_group(char *user, int ngroups, const char **groups)
+modify_group(char *user, int ngroups, const char **groups)
{
struct group*grp;
struct stat st;
@@ -500,20 +500,19 @@
int cc;
int i;
int j;
+ int c ;
+ int d ;
+ int l ;
+ /* Check groups are valid */
for (i = 0 ; i < ngroups ; i++) {
if ((grp = getgrnam(groups[i])) == NULL) {
warnx("can't append group `%s' for user `%s'",
groups[i], user);
- } else {
- for (j = 0 ; grp->gr_mem[j] ; j++) {
- if (strcmp(user, grp->gr_mem[j]) == 0) {
- /* already in it */
- groups[i] = "";
- }
- }
}
}
+
+ /* Open and lock files */
if ((from = fopen(_PATH_GROUP, "r")) == NULL) {
warn("can't append group for `%s': can't open `%s'", user,
_PATH_GROUP);
@@ -536,7 +535,10 @@
warn("can't append group: fdopen `%s' failed", f);
return 0;
}
+
while (fgets(buf, sizeof(buf), from) != NULL) {
+
+ /* Load entry from file */
cc = strlen(buf);
if (cc > 0 && buf[cc - 1] != '\n' && !feof(from)) {
while (fgetc(from) != '\n' && !feof(from))
@@ -545,30 +547,53 @@
_PATH_GROUP, buf, cc);
continue;
}
- if ((colon = strchr(buf, ':')) == NULL) {
+ while (isspace(buf[cc-1])) cc-- ;
+ buf[cc]='\0' ;
+
+/* Remove username from list */
+ for (c=0,d=0; buf[c]!=':' && buf[c]!='\0'; c++,d++) ;
+ if (buf[d]==':') d++ ;
+ for (; buf[d]!=':' && buf[d]!='\0'; d++) ;
+ if (buf[d]==':') d++ ;
+ for (; buf[d]!=':' && buf[d]!='\0'; d++) ;
+ if (buf[d]!=':') {
warnx("badly formed entry `%s'", buf);
continue;
}
+ l=strlen(user) ;
+ for (i=d; buf[i]!='\0' &&
+ !(strncmp(user, &buf[i], l)==0 &&
+ !isalnum(buf[i+l])); i++) ;
+ if (buf[i]!='\0') {
+ if (buf[i-1]==',') { i-- ; l++ ; }
+ else if (buf[i-1]==':') { l++ ; }
+ for (i+=l; buf[i]!='\0'; i++)
+ buf[i-l]=buf[i] ;
+ buf[i-l]='\0' ;
+ cc=strlen(buf) ;
+ }
+
+ /* Append username to list if in group */
for (i = 0 ; i < ngroups ; i++) {
- j = (int)(colon - buf);
+ j = (int)c ;
if (strncmp(groups[i], buf, j) == 0 &&
groups[i][j] == '\0') {
- while (isspace(buf[cc - 1]))
- cc--;
- buf[(j = cc)] = '\0';
- if (buf[strlen(buf) - 1] != ':')
+ j=cc ;
+ if (buf[strlen(buf)] != ':')
strlcat(buf, ",", sizeof(buf));
- cc = strlcat(buf, user, sizeof(buf)) + 1;
- if (cc >= sizeof(buf)) {
+ cc = strlcat(buf, user, sizeof(bu
Re: disklabel -F|-f should print swap partitions too.
On Sun, Apr 17, 2011 at 07:26:28AM +0100, Jason McIntyre wrote: > On Sat, Apr 16, 2011 at 07:29:27PM -0400, Kenneth R Westerback wrote: > > > > My suggested man page tweaks are below. > > > > Ken > > > > Index: share/man/man5/fstab.5 > > === > > RCS file: /cvs/src/share/man/man5/fstab.5,v > > retrieving revision 1.44 > > diff -u -p -r1.44 fstab.5 > > --- share/man/man5/fstab.5 28 Sep 2010 17:37:20 - 1.44 > > +++ share/man/man5/fstab.5 16 Apr 2011 23:26:22 - > > @@ -284,7 +284,8 @@ swap /tmp mfs rw,nodev,nosuid,-s=153600 > > /dev/sd0h /usr/local ffs rw,nodev 1 2 > > /dev/sd0i /home ffs rw,nodev,nosuid 1 2 > > /dev/sd0j /usr/src ffs rw,nodev,nosuid,softdep 1 2 > > -/dev/sd1b none swap sw 0 0 > > +/dev/sd0b none swap sw > > +/dev/sd1b none swap sw > > i would probably leave out the sd0b entry, just because we are already > showing an mfs entry. > > > /dev/cd0a /cdrom cd9660 ro,noauto 0 0 > > 5b27c2761a9b0b06.i /mnt/key msdos rw,noauto 0 0 > > server:/export/ports /usr/ports nfs rw,nodev,nosuid,soft,intr 0 0 > > Index: sbin/swapctl/swapctl.8 > > === > > RCS file: /cvs/src/sbin/swapctl/swapctl.8,v > > retrieving revision 1.30 > > diff -u -p -r1.30 swapctl.8 > > --- sbin/swapctl/swapctl.8 3 Sep 2010 10:08:22 - 1.30 > > +++ sbin/swapctl/swapctl.8 16 Apr 2011 23:26:22 - > > @@ -74,9 +74,7 @@ it acts as > > .Pp > > .Sy Note : > > The initial swap device (root disk, partition b) is handled automatically > > -by the kernel and does > > -.Em not > > -need to be added to > > +by the kernel and does not need to be added to > > .Pa /etc/fstab > > or added via > > .Nm swapctl . > > @@ -85,6 +83,9 @@ It will show up as > > in the output displayed with the > > .Fl l > > flag. > > +If present in > > +.Pa /etc/fstab > > +it will be silently ignored. > > theo suggested that this block of text just be removed. i think i agree > with that - it's now looking more likely to confuse people than help. > > > .Pp > > The options are as follows: > > .Bl -tag -width Ds > > @@ -173,7 +174,7 @@ When parsing the > > file for swap devices, lines such as the following specify additional swap > > devices: > > .Bd -literal -offset indent > > -/dev/sd1b none swap sw 0 0 > > +/dev/sd1b none swap sw > > .Ed > > .Pp > > Additional flags include: > > > > otherwise i'm ok with the changes. > jmc > I am uncomfortable with removing the swapctl verbiasge, but I think it is much more digestable if broken up and distributed as below. I moved the swap lines in the example to the top, where they are likely to have been put by the install process. Keeping sd0b seems better to me, but marginally so. Ken Index: sbin/swapctl/swapctl.8 === RCS file: /cvs/src/sbin/swapctl/swapctl.8,v retrieving revision 1.30 diff -u -p -r1.30 swapctl.8 --- sbin/swapctl/swapctl.8 3 Sep 2010 10:08:22 - 1.30 +++ sbin/swapctl/swapctl.8 17 Apr 2011 16:29:18 - @@ -72,20 +72,6 @@ in which case it acts as .Ic swapctl -A . .Pp -.Sy Note : -The initial swap device (root disk, partition b) is handled automatically -by the kernel and does -.Em not -need to be added to -.Pa /etc/fstab -or added via -.Nm swapctl . -It will show up as -.Qq swap_device -in the output displayed with the -.Fl l -flag. -.Pp The options are as follows: .Bl -tag -width Ds .It Fl A @@ -136,6 +122,8 @@ option uses 1024 byte blocks instead of The .Fl l option lists the current swap devices and files, and their usage statistics. +The initial swap device (root disk, partition b) will show up as +.Qq swap_device . .It Fl p Ar priority The .Fl p @@ -168,13 +156,16 @@ may be needed before all file systems ar disk checks of large file systems. .El .Sh SWAP OPTIONS -When parsing the .Pa /etc/fstab -file for swap devices, lines such as the following specify additional swap -devices: +lines such as the following specify swap devices: .Bd -literal -offset indent -/dev/sd1b none swap sw 0 0 +/dev/sd1b none swap sw +d48d0e3fc1c39531.k none swap sw .Ed +.Pp +The initial swap device (root disk, partition b) does not need to appear in +.Pa /etc/fstab , +although it can. .Pp Additional flags include: .Pp Index: share/man/man5/fstab.5 === RCS file: /cvs/src/share/man/man5/fstab.5,v retrieving revision 1.44 diff -u -p -r1.44 fstab.5 --- share/man/man5/fstab.5 28 Sep 2010 17:37:20 - 1.44 +++ share/man/man5/fstab.5 17 Apr 2011 16:29:18 - @@ -276,6 +276,8 @@ Here is a sample .Pa /etc/fstab file: .Bd -literal -offset indent +/dev/sd0b none swap sw +/dev/sd1b none swap sw /dev/sd0a / ffs rw 1 1 /dev/sd0e /var ffs rw,nodev,nosuid 1 2 #/dev/sd0f /tmp ffs rw,nodev,nosuid 1 2 @@ -284,7 +286,6 @@ swap /tmp mfs rw,nodev,nosuid,-s=153600 /dev/s
isakmpd, one of two tunnels broken, extra SAs
I have various isakmpd clients behind NAT, connecting to a central isakmpd box. They have two tunnels to the same central box for different networks; occasionally one of them stops functioning correctly. I managed to catch one today before the user rebooted it and noticed something odd so I thought I'd write it up, partly so others know about the problem, and partly to clarify it in my head. First I'll describe the setup. The central site is on a single machine: no sasyncd, no pfsync. Endpoints are all behind NAT so it's all 'ike dynamic esp' with DPD. Client boxes setup tunnels between their own 192.168.46.xx/28 network and both of 192.168.40.0/21 and $SOME_NET/24. There are also bypass flows for 192.168.46.xx/28 so local traffic isn't handled by ipsec. So in normal use things look like this: FLOWS: flow esp in from 192.168.40.0/21 to 192.168.46.64/27 peer $CENTRAL_BOX srcid foo dstid $CENTRAL_BOX/32 type use flow esp out from 192.168.46.64/27 to 192.168.40.0/21 peer $CENTRAL_BOX srcid foo dstid $CENTRAL_BOX/32 type require flow esp in from $SOME_NET/24 to 192.168.46.64/27 peer $CENTRAL_BOX srcid foo dstid $CENTRAL_BOX/32 type use flow esp out from 192.168.46.64/27 to $SOME_NET/24 peer $CENTRAL_BOX srcid foo dstid $CENTRAL_BOX/32 type require flow esp in from 192.168.46.64/27 to 192.168.46.64/27 type bypass flow esp out from 192.168.46.64/27 to 192.168.46.64/27 type bypass SAD: esp tunnel from 192.168.1.33 to $CENTRAL_BOX spi 0x45182c71 auth hmac-sha1 enc aes esp tunnel from 192.168.1.33 to $CENTRAL_BOX spi 0x478235ac auth hmac-sha1 enc aes esp tunnel from $CENTRAL_BOX to 192.168.1.33 spi 0x48d960e9 auth hmac-sha1 enc aes esp tunnel from $CENTRAL_BOX to 192.168.1.33 spi 0x606a6c9e auth hmac-sha1 enc aes When the 192.168.40.0/21 tunnel stopped working on this box, there were the usual SAs/flows, but also two additional SAs listed. These are present both on the NATted endpoint and the central site: esp tunnel from $CENTRAL_BOX to 192.168.1.33 spi 0x04003c27 auth hmac-sha1 enc aes esp tunnel from $CENTRAL_BOX to 192.168.1.33 spi 0x533787fc auth hmac-sha1 enc aes esp tunnel from 192.168.1.33 to $CENTRAL_BOX spi 0x664d3a34 auth hmac-sha1 enc aes esp tunnel from $CENTRAL_BOX to 192.168.1.33 spi 0x7eb09787 auth hmac-sha1 enc aes esp tunnel from 192.168.1.33 to $CENTRAL_BOX spi 0xc6f132bf auth hmac-sha1 enc aes esp tunnel from 192.168.1.33 to $CENTRAL_BOX spi 0xccc434bc auth hmac-sha1 enc aes Traffic sent from machines inside 192.168.40.0/21 (central network) to 192.168.46.65 (client network) was showing up on enc0 on the central box with spi 0x04003c27, and not showing up on enc0 on the client box. When the 192.168.4x.xx tunnel was failing, the central site was sending traffic on the 0x04003c27 SA. >From looking at this I've worked out that I should collect an isakmpd.result and see what SAs are showing up there (and I'll write something to detect the extra SAs showing up). If anyone has ideas on further things to collect next time it happens please let me know...
Re: fenv.h support for libm
The diff I sent before has been corrupted by Gmail (wrapped diff lines). I'm re-attaching it below. Index: include/Makefile === RCS file: /cvs/src/include/Makefile,v retrieving revision 1.157 diff -u -r1.157 Makefile --- include/Makefile28 Oct 2010 08:34:37 - 1.157 +++ include/Makefile18 Mar 2011 17:20:42 - @@ -12,8 +12,8 @@ # Missing: mp.h FILES= a.out.h ar.h assert.h bitstring.h blf.h bm.h bsd_auth.h \ complex.h cpio.h ctype.h curses.h db.h dbm.h des.h dirent.h disktab.h \ - dlfcn.h elf_abi.h err.h errno.h fnmatch.h fstab.h fts.h ftw.h getopt.h \ - glob.h grp.h ifaddrs.h inttypes.h iso646.h kvm.h langinfo.h \ + dlfcn.h elf_abi.h err.h errno.h fenv.h fnmatch.h fstab.h fts.h ftw.h \ + getopt.h glob.h grp.h ifaddrs.h inttypes.h iso646.h kvm.h langinfo.h \ libgen.h limits.h locale.h login_cap.h malloc.h math.h md4.h \ md5.h memory.h mpool.h ndbm.h netdb.h netgroup.h nlist.h nl_types.h \ ohash.h paths.h poll.h pwd.h ranlib.h re_comp.h \ Index: include/fenv.h === RCS file: include/fenv.h diff -N include/fenv.h --- /dev/null 1 Jan 1970 00:00:00 - +++ include/fenv.h 16 Apr 2011 21:26:26 - @@ -0,0 +1,59 @@ +/* $OpenBSD$ */ +/* $NetBSD: fenv.h,v 1.2.4.1 2011/02/08 16:18:55 bouyer Exp $ */ + +/* + * Copyright (c) 2010 The NetBSD Foundation, Inc. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +#ifndef_FENV_H_ +#define_FENV_H_ + +#include +#include + +__BEGIN_DECLS + +intfeclearexcept(int); +intfegetexceptflag(fexcept_t *, int); +intferaiseexcept(int); +intfesetexceptflag(const fexcept_t *, int); +intfetestexcept(int); + +intfegetround(void); +intfesetround(int); +intfegetenv(fenv_t *); +intfeholdexcept(fenv_t *); +intfesetenv(const fenv_t *); +intfeupdateenv(const fenv_t *); + +#if__BSD_VISIBLE +intfeenableexcept(int mask); +intfedisableexcept(int mask); +intfegetexcept(void); +#endif /* __BSD_VISIBLE */ + +__END_DECLS + +#endif /* ! _FENV_H_ */ Index: sys/arch/amd64/include/fenv.h === RCS file: sys/arch/amd64/include/fenv.h diff -N sys/arch/amd64/include/fenv.h --- /dev/null 1 Jan 1970 00:00:00 - +++ sys/arch/amd64/include/fenv.h 18 Mar 2011 20:37:58 - @@ -0,0 +1,105 @@ +/* $OpenBSD$ */ +/* $NetBSD: fenv.h,v 1.1 2010/07/31 21:47:54 joerg Exp $ */ + +/*- + * Copyright (c) 2004-2005 David Schultz + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DA
Re: wol for xl(4)
On Thu, Mar 31, 2011 at 06:54:44PM +0200, Stefan Sperling wrote:
> This is an attempt to add wol support to xl(4).
>
> Unfortunately, while I have an xl(4) card to test with none of the
> motherboards I have will do WOL with it since they all lack an
> on-board WOL connector :(
>
> So test reports are needed.
> Please also check whether WOL is disabled by default.
I haven't received any test reports yet.
If someone could donate a motherboard with a wol connector, preferrably
with suitable cpu and ram, that would help with getting wol support for
this and some other drivers for similarly old hardware.
It doesn't need to be a fast machine. I just need a board that has a connector.
>
> Index: ic/xl.c
> ===
> RCS file: /cvs/src/sys/dev/ic/xl.c,v
> retrieving revision 1.99
> diff -u -p -r1.99 xl.c
> --- ic/xl.c 22 Sep 2010 08:49:14 - 1.99
> +++ ic/xl.c 31 Mar 2011 15:48:36 -
> @@ -191,6 +191,9 @@ void xl_testpacket(struct xl_softc *);
> int xl_miibus_readreg(struct device *, int, int);
> void xl_miibus_writereg(struct device *, int, int, int);
> void xl_miibus_statchg(struct device *);
> +#ifndef SMALL_KERNEL
> +int xl_wol(struct ifnet *, int);
> +#endif
>
> int
> xl_activate(struct device *self, int act)
> @@ -2368,6 +2371,12 @@ xl_stop(struct xl_softc *sc)
> ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE);
>
> xl_freetxrx(sc);
> +
> +#ifndef SMALL_KERNEL
> + /* Call upper layer WOL power routine if WOL is enabled. */
> + if ((sc->xl_flags & XL_FLAG_WOL) && sc->wol_power)
> + sc->wol_power(sc->wol_power_arg);
> +#endif
> }
>
> void
> @@ -2637,6 +2646,15 @@ xl_attach(struct xl_softc *sc)
> CSR_WRITE_2(sc, XL_W0_MFG_ID, XL_NO_XCVR_PWR_MAGICBITS);
> }
>
> +#ifndef SMALL_KERNEL
> + /* Check availability of WOL. */
> + if ((sc->xl_caps & XL_CAPS_PWRMGMT) != 0) {
> + ifp->if_capabilities |= IFCAP_WOL;
> + ifp->if_wol = xl_wol;
> + xl_wol(ifp, 0);
> + }
> +#endif
> +
> /*
>* Call MI attach routines.
>*/
> @@ -2668,6 +2686,24 @@ xl_detach(struct xl_softc *sc)
>
> return (0);
> }
> +
> +#ifndef SMALL_KERNEL
> +int
> +xl_wol(struct ifnet *ifp, int enable)
> +{
> + struct xl_softc *sc = ifp->if_softc;
> +
> + XL_SEL_WIN(7);
> + if (enable) {
> + CSR_WRITE_2(sc, XL_W7_BM_PME, XL_BM_PME_MAGIC);
> + sc->xl_flags |= XL_FLAG_WOL;
> + } else {
> + CSR_WRITE_2(sc, XL_W7_BM_PME, 0);
> + sc->xl_flags &= ~XL_FLAG_WOL;
> + }
> + return (0);
> +}
> +#endif
>
> struct cfdriver xl_cd = {
> 0, "xl", DV_IFNET
> Index: ic/xlreg.h
> ===
> RCS file: /cvs/src/sys/dev/ic/xlreg.h,v
> retrieving revision 1.26
> diff -u -p -r1.26 xlreg.h
> --- ic/xlreg.h21 Sep 2010 01:05:12 - 1.26
> +++ ic/xlreg.h31 Mar 2011 15:42:36 -
> @@ -411,6 +411,12 @@
> #define XL_W7_BM_LEN 0x06
> #define XL_W7_BM_STATUS 0x0B
> #define XL_W7_BM_TIMEr 0x0A
> +#define XL_W7_BM_PME 0x0C
> +
> +#define XL_BM_PME_WAKE 0x0001
> +#define XL_BM_PME_MAGIC 0x0002
> +#define XL_BM_PME_LINKCHG 0x0004
> +#define XL_BM_PME_WAKETIMER 0x0008
>
> /*
> * bus master control registers
> @@ -571,6 +577,7 @@ struct xl_mii_frame {
> #define XL_FLAG_NO_XCVR_PWR 0x0080
> #define XL_FLAG_USE_MMIO 0x0100
> #define XL_FLAG_NO_MMIO 0x0200
> +#define XL_FLAG_WOL 0x0400
>
> #define XL_NO_XCVR_PWR_MAGICBITS 0x0900
>
> @@ -604,6 +611,8 @@ struct xl_softc {
> caddr_t sc_listkva;
> bus_dmamap_tsc_rx_sparemap;
> bus_dmamap_tsc_tx_sparemap;
> + void (*wol_power)(void *);
> + void *wol_power_arg;
> };
>
> #define xl_rx_goodframes(x) \
> @@ -740,6 +749,13 @@ struct xl_stats {
> #define XL_PSTATE_D3 0x0003
> #define XL_PME_EN0x0010
> #define XL_PME_STATUS0x8000
> +
> +/* Bits in the XL_PCI_PWRMGMTCAP register */
> +#define XL_PME_CAP_D00x0800
> +#define XL_PME_CAP_D10x1000
> +#define XL_PME_CAP_D20x2000
> +#define XL_PME_CAP_D3_HOT0x4000
> +#define XL_PME_CAP_D3_COLD 0x8000
>
> extern int xl_intr(void *);
> extern void xl_attach(struct xl_softc *);
> Index: pci/if_xl_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_xl_pci.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 if_xl_pci.c
> --- pci/if_xl_pci.c 19 Sep 2010 09:22:58 - 1.34
> +++ pci/if_xl_pci.c 31 Mar 2011 15:43:05 -
> @@ -92,10 +92,14 @@ int xl_pci_match(struct device *, void *
> void xl_pci_attach(struct device *, struct device *
Re: isprint() needs setlocale(); for usr.bin
On Tue, Apr 05, 2011 at 12:25:37AM +0200, Stefan Sperling wrote:
> For isprint() to work correctly in a UTF-8 locale applications must
> set up the LC_CTYPE locale before using isprint().
>
> As done for hexdump and tcpdump already.
>
> This diff covers all offenders in usr.bin.
Todd Miller suggested using LC_ALL instead of LC_CTYPE so we don't have
to revisit these when we add support for more categories.
Index: bc/bc.y
===
RCS file: /cvs/src/usr.bin/bc/bc.y,v
retrieving revision 1.34
diff -u -p -r1.34 bc.y
--- bc/bc.y 7 Mar 2011 08:11:15 - 1.34
+++ bc/bc.y 4 Apr 2011 21:32:29 -
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1088,6 +1089,7 @@ main(int argc, char *argv[])
int p[2];
char*q;
+ setlocale(LC_ALL, "");
init();
setlinebuf(stdout);
Index: bgplg/bgplgsh.c
===
RCS file: /cvs/src/usr.bin/bgplg/bgplgsh.c,v
retrieving revision 1.3
diff -u -p -r1.3 bgplgsh.c
--- bgplg/bgplgsh.c 2 Apr 2010 21:20:49 - 1.3
+++ bgplg/bgplgsh.c 4 Apr 2011 21:41:52 -
@@ -20,6 +20,7 @@
#include
#include
+#include
#include
#include
#include
@@ -225,6 +226,7 @@ main(void)
/* Ignore the whitespace character */
rl_basic_word_break_characters = "\t\n\"\\'`@$><=;|&{(";
+ setlocale(LC_ALL, "");
while (!quit) {
v = -1;
gethostname(prompt, sizeof(prompt) - 2);
Index: chpass/chpass.c
===
RCS file: /cvs/src/usr.bin/chpass/chpass.c,v
retrieving revision 1.37
diff -u -p -r1.37 chpass.c
--- chpass/chpass.c 27 Oct 2009 23:59:36 - 1.37
+++ chpass/chpass.c 4 Apr 2011 21:34:44 -
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -74,6 +75,9 @@ main(int argc, char *argv[])
#ifdef YP
use_yp = _yp_check(NULL);
#endif
+
+ setlocale(LC_ALL, "");
+
/* We need to use the system timezone for date conversions. */
if ((tz = getenv("TZ")) != NULL) {
unsetenv("TZ");
Index: cvs/cvs.c
===
RCS file: /cvs/src/usr.bin/cvs/cvs.c,v
retrieving revision 1.151
diff -u -p -r1.151 cvs.c
--- cvs/cvs.c 23 Jul 2010 08:31:19 - 1.151
+++ cvs/cvs.c 4 Apr 2011 21:36:04 -
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -188,6 +189,7 @@ main(int argc, char **argv)
char fpath[MAXPATHLEN];
tzset();
+ setlocale(LC_ALL, "");
TAILQ_INIT(&cvs_variables);
SLIST_INIT(&repo_locks);
Index: diff/diff.c
===
RCS file: /cvs/src/usr.bin/diff/diff.c,v
retrieving revision 1.57
diff -u -p -r1.57 diff.c
--- diff/diff.c 16 Jul 2010 23:27:58 - 1.57
+++ diff/diff.c 4 Apr 2011 21:38:23 -
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -87,6 +88,7 @@ main(int argc, char **argv)
long l;
int ch, dflags, lastch, gotstdin, prevoptind, newarg;
+ setlocale(LC_ALL, "");
oargv = argv;
gotstdin = 0;
dflags = 0;
Index: finger/finger.c
===
RCS file: /cvs/src/usr.bin/finger/finger.c,v
retrieving revision 1.18
diff -u -p -r1.18 finger.c
--- finger/finger.c 12 Nov 2009 15:33:21 - 1.18
+++ finger/finger.c 4 Apr 2011 21:41:09 -
@@ -59,6 +59,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -84,6 +85,8 @@ main(int argc, char *argv[])
struct stat sb;
oflag = 1; /* default to old "office" behavior */
+
+ setlocale(LC_ALL, "");
while ((ch = getopt(argc, argv, "lmMpsho")) != -1)
switch(ch) {
Index: grep/grep.c
===
RCS file: /cvs/src/usr.bin/grep/grep.c,v
retrieving revision 1.43
diff -u -p -r1.43 grep.c
--- grep/grep.c 4 Mar 2011 03:11:23 - 1.43
+++ grep/grep.c 4 Apr 2011 21:44:00 -
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -236,6 +237,8 @@ main(int argc, char *argv[])
struct patfile *patfile, *pf_next;
long l;
char *ep, **expr;
+
+ setlocale(LC_ALL, "");
SLIST_INIT(&patfilelh);
switch (__progname[0]) {
Index: infocmp/infocmp.c
===
RCS file: /cvs/src/usr.bin/infocmp/infocmp.c,v
retrieving revision 1.20
diff -u -p -r1.20 infocmp.c
--- infocmp/infocmp.c 12 Jan 2010 23:22:13 - 1.20
+++ infocmp/infocmp.c 4 Apr 2011 21:46:04 -
@@ -
Re: if_ath oerrors with multicast traffic
On Wed, Apr 06, 2011 at 10:41:14PM +0200, Stefan Sperling wrote: > There is a correlation between netstat -I ath0 showing more Oerrs and > multicast packets (e.g. CARP) leaving the interface. There is no apparent > real problem since these frames are received just fine at the other end. > The diff below stops the driver from doing this. Is this right? Anyone? > BTW, there doesn't seem to be any in-tree userland tool to print stats > reported by the SIOCGATHSTATS ioctl. Is one available anywhere? > > Index: ath.c > === > RCS file: /cvs/src/sys/dev/ic/ath.c,v > retrieving revision 1.91 > diff -u -p -r1.91 ath.c > --- ath.c 7 Sep 2010 16:21:42 - 1.91 > +++ ath.c 6 Apr 2011 20:02:37 - > @@ -2488,7 +2488,6 @@ ath_tx_proc(void *arg, int npending) > if (bf->bf_id.id_node != NULL) > ieee80211_rssadapt_lower_rate(ic, ni, > &an->an_rssadapt, &bf->bf_id); > - ifp->if_oerrors++; > if (ds->ds_txstat.ts_status & HAL_TXERR_XRETRY) > sc->sc_stats.ast_tx_xretries++; > if (ds->ds_txstat.ts_status & HAL_TXERR_FIFO)
