Re: Lack of real long double support
Thus spake M. Warner Losh [EMAIL PROTECTED]: : No. You should assume that for i386, at least, that long double will : have the right LDBL_ constants. I've had them in my local tree for : about 3 months now and just haven't found the time to commit to : -current. I'll find the time right now. I've committed the fix to the tree. NetBSD uses these numbers, and I've been using these numbers on a large number of systems that we maintain at timing solutions (they were added to our local tree prior to the 4.5 release, and we've built hundreds of ports since then w/o any issues). I've had them in my own personal p4 tree for 3 months with similar results. I submitted patches for this back in May. Could you please close i386/38288? While you're at it, you should probably patch IA64 as well. Other supported platforms should be okay, I think. TIA. (Every time this happens, someone comes along a month later and tells me that _I'm_wrong_ about there ever being a bug.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
Thus spake Tim Kientzle [EMAIL PROTECTED]: Thus spake Lucky Green [EMAIL PROTECTED]: ... remove ssh1 fallback from the default ... David Schultz [EMAIL PROTECTED] wrote: Removing SSH 1 ... is going to break compatibility ... POLA: before breaking compatibility, warn people. It's simple to modify the ssh client so that it emits a warning message before downgrading Warning: switching to less-secure SSH1 protocol On the server side, you could certainly log a warning; there may be a way to notify the connecting user as well. The logged warning could even include a very brief reference to the setting required to disable SSH1 entirely. I think you're missing the point. Warnings are fine, but there is little good reason to disable SSH1 entirely. If one end of the connection is forced to fall back to SSH1, it's almost certainly because the user at the other end _doesn't_have_any_other_option_. You're proposing to kick legitimate users off of everyone's FreeBSD boxen because you know better than they do about security. I know SSH1 is insecure, and therefore I don't use it. But I'm not about to unleash a surprise on everyone who uses a machine without SSH2 just so I can hammer the idea into their heads. Breaking POLA isn't a sin, but you'd better have a better reason to do it than ``it lets people do things that are insecure.'' So do rsh, telnet, hosts.equiv, vipw, et al. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
Thus spake Doug Rabson [EMAIL PROTECTED]: Move the resolver code out to ibresolv.so, and link libc.so against libresolv.so so that legacy applications are happy, as long as they are compiled shared. Non-network apps can ignore most of it. Internal use of some of the biggest chunks is limited, so this should avoid dragging in a lot of it. We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the oops! and other foot shooting problems. Yes please. Our root filesystem space requirements are too high, IMHO. Why is it absolutely necessary to dynamically link everything just to move the resolver out of libc? I'm all for doing the latter, but I think dynamically linking /bin and /sbin is a really bad idea, for several reasons: - If the single user mode runtime includes several shared libraries, you have several additional points of failure. - The use of shared libraries incurs a performance hit for programs like sh and echo, which should be fast. o Exec time is greatly increased because you have to map in the libraries. o The -fPIC code in the shared libraries is slower, particularly on the register-starved i386. o The VM system has to do more work when you have a sparse virtual memory map, which is what you get when you stick shared libraries in the middle of your address space. - Using shared libraries for trusted binaries like sh has negative consequences for security. For example, a `feature' of OpenSSH allows users to circumvent restrictions imposed using /sbin/nologin, provided that /sbin/nologin is dynamically linked. I don't think the disk space argument outweighs these problems. There are a few binaries in /sbin that are bigger than they ought to be, but it isn't as though /bin and /sbin occupy 500 MB. Memory is even less of an issue; if a thousand copies of a shell are running, their text gets shared regardless of how they are linked. I have run into problems with dynamic linking in the past. In one case, I couldn't log into a Linux machine because the administrator (who used bash, of course) had tcsh linked against a version of glibc that didn't exist on his system. I would really hate to see FreeBSD open itself up to the same kinds of foot-shooting opportunities just because of the resolver, or for the sake of a few dozen megs of disk space. Of all things, don't dynamically link my shell. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
Thus spake Terry Lambert [EMAIL PROTECTED]: David Schultz wrote: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the oops! and other foot shooting problems. Yes please. Our root filesystem space requirements are too high, IMHO. Why is it absolutely necessary to dynamically link everything just to move the resolver out of libc? Because ELF supports linking a shared library to another shared library, which will automatically get you the appearance of the historical libresolv is integrated into libc. But it does not support the linking of a static library to a static library, or a static library to a shared library, the same way. At least in the case of the base system, it should be easy to link all programs that actually use the resolver with -lresolv. Is there some standard that says that the resolver is an integral part of the C library, such that separating the two would break compatibility beyond comprehension? If you wanted to be really evil, I suppose you could have a libc.a that included the resolver and a libc.so that didn't. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lack of real long double support
Thus spake Bruce Evans [EMAIL PROTECTED]: $ cc -o z z.c $ ./z LDBL_EPSILON failed test 1 with prec 2 $ cc -O -o z z.c. $ ./z LDBL_EPSILON failed test 1 with prec 2 DBL_EPSILON failed test 2 with prec 3 %%% The full brokenness only shows up with -O. Actually, the _full_ brokenness of floating point in FreeBSD shows up only with -O2. :-( A number of library functions (e.g. isinf()) use unions for type punning, which violates C's aliasing rules. It turns out that there's a bad interaction between gcc3's -fschedule-insns and -fstrict-aliasing (both implied by -O2) that can cause problems. The best fix I know of is to use unions in the limited way that gcc's optimizer knows how to handle in a reasonable way. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libc size
Thus spake Miguel Mendez [EMAIL PROTECTED]:
Why? I'd love to hear some real reasons for this. NetBSD-current has
just gone fully dynamic, let's see how much space that needs...
christine: {16} uname -srnm
NetBSD christine.energyhq.tk 1.6J i386
christine: {17} du -h /bin /sbin /lib
999K/bin
1.7M/sbin
2.0M/lib
/lib keeps the required shared libs for those programs residing in
/[s]bin.
IMHO it would be beneficial to, at least, have the option to build a
fully dynamic system on FreeBSD.
Keep in mind that NetBSD's /bin and /sbin were significantly
smaller beforehand. FreeBSD's equivalent is somewhat bloated, but
it's not so unreasonably large that people are having trouble
making it fit on hard drives purchased in the last four years. If
you're installing FreeBSD on an embedded system, that's one thing,
but you have PicoBSD for that. Otherwise, you're sacrificing
performance, reliability, and security for the sake of a few dozen
megs of disk space. I don't think this is an acceptable tradeoff.
I'm not opposed to having a knob that allows people to dynamically
link their /bin and /sbin if they so desire, as long as it's done
right. I worry a little bit that once the feature is available,
someone will decide that it's a bright idea to turn it on by
default, and support for the static linking case will decline.
(This is similar to what happened with GEOM, although I happen to
be all in favor of the latter. C'est la vie.)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libc size
Thus spake Robert Watson [EMAIL PROTECTED]: I can't come up right now with an idea of how exploiting LD_LIBRARY_PATH could be useful with any of these, but the possibility exists. OTOH, the recently added priviledge elevation feature should make it possible to have *no* setuid programs on a system, and have the kernel elevate priviledges for certain syscalls, based on the policy created by systrace. LD_LIBRARY_PATH is disabled for setuid binaries -- the kernel sets the P_ISSETUGID flag, which is exported to userspace by issetugid(), which is in turn checked by the rtld, which will refuse to observe that environmental variable (and a number of others) as a result. We have plenty of dynamically linked setuid binaires in the system already, and it's not a problem. Setuid binaries are in pretty good shape, since LD_LIBRARY_PATH is ignored for them. But most of the other standard binaries on the system are problematic because they are trusted, but they in turn trust the value of LD_LIBRARY_PATH, which is not always a safe thing to do. For example, if an administrator disables a user's account by setting the shell to a dynamically linked /sbin/nologin, the user can override the restriction by setting an LD_LIBRARY_PATH in his ~.ssh/environment file pointing to a trojaned libc. (This attack requires that he be able to access his home directory, either before being locked out or over NFS or FTP.) You can correctly argue that setting a user's shell to /sbin/nologin is the wrong way to disable the account. Fine. Remove /sbin/nologin. I still claim that this is just one example of what can go wrong when you divide trust between libc and your standard binaries. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SMP broken on PPro
Thus spake Glenn Johnson [EMAIL PROTECTED]: I have had no trouble with UP -STABLE running on a dual PPro system, but I'm getting an early panic in UP and SMP -CURRENT on the same system. I will post details to current@ soon if I can't figure out the problem. The problem on -STABLE is with /sys/i386/i386/machdep.c, revision 1.385.2.26. I am not smart enough to know exactly what is wrong with the diff but reverting back to revision 1.385.2.25 of /sys/i386/i386/machdep.c fixes the problem. Aah yes, this is an MFC of revision 1.544, which broke -CURRENT as well. The patch should probably be un-MFC'd until a better solution is found. The old code said: 1) set up some PTEs for the BIOS just before the 640K mark if the BIOS may be using that space 2) call int 15 function E820 to get the memory map from the BIOS The new code reverses the order of these operations, so it causes a segfault in the BIOS interrupt handler. I recall a thread about this change on current@ a little while ago, but I forget exactly what problem it was supposed to solve. As for the fix, I'm not a PC BIOS expert, but I don't see any reason why it's necessary to call 15:E820 *before* good old int12, which ought to work on any BIOS dating back to the original PC-XT. If there's some problem I don't know about, I should note that the machine that triggers this bug for me works fine on the first 15:E820 call but not the second. If other BIOSes behave similarly, one possible fix would be to interpret the return value from the first 15:E820 call specially, e.g. if (smap-base == 0 smap-length 640*1024) set up some PTEs for the gap; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel not booting....Immediate crash
Thus spake Michael G. Petry [EMAIL PROTECTED]: I'm noticing the same behavior on a PPro system I have and am following the thread SMP broken on PPro. It looks like the problem is not SMP specific, but it does seem PPro centric. I observed the problem on a PPro as well, but it is not specific to PPros. It will occur on any BIOSes (mostly older ones) that use a small amount of memory right before the 640K mark. The problem is that the person who committed the broken change didn't understand that you have to map this region into virtual memory if you're going to call the BIOS in protected mode. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel not booting....Immediate crash
Thus spake Sidcarter [EMAIL PROTECTED]: Fatal trap 12: page fault while in vm86 mode fault virtual address = 0x9fdc8 ^^^ That's a region of memory right before the 640K mark, and your BIOS is trying to use it. This used to work, but revision 1.544 of src/sys/i386/i386/machdep.c moved the code that mapped in those pages until *after* they need to be used. I (unsuccessfully) petitioned the committer who made the change to revert it, so for now you'll have to manually remove it, being careful not to step on the changes introduced in revisions 1.545 through 1.547. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel not booting....Immediate crash
Thus spake Mitsuru IWASAKI [EMAIL PROTECTED]: Hmmm, I didn't notice that there is a BIOS which requires memory area below 640K even when calling INT 15H/E820. We cannot trust that today's BOISes have INT 12H, so it's difficult to determine base memory size w/o INT 15H/E820. You keep saying this, which really surprises me, because the int 12h interface has been standard for over two decades. I have not heard any great clammoring that DOS and NetBSD fail to boot on modern machines, and yet they both use int 12h. Are you *sure* int 12h is really broken, or do you think perhaps the breakage you're seeing is a side-effect of another bug? Does int 12h work in real mode? Exactly what hardware has this problem? Also, you mentioneded earlier that Linux doesn't use int 12h anymore. But notice that they call 15:E820 in real mode, rather than turning on virtual memory and then temporarily mapping an arbitrary chunk of the first 640K of RAM. Why don't you just put the memory size detection code in locore.s? I'd be happy to help out with this, although my time is constrained after Monday. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: adaptec scsi - seagate da -- current
Thus spake Justin T. Gibbs [EMAIL PROTECTED]: I am running current cvsuped within this week. I have an adaptec builtin scsi controller and a seagate drive attached to it and after every bootup as soon as there is heavy disk activity the drive gets disabled for 1 or 2 minutes and meanwhile all functionality RELATED to disk I/O freezes for this time duration eventually I see the following messages on console and every thing is hunky dorry again. Have had this problem ever since I upgraded to current. Stable never had any problem. neither did netbsd which ran on this machine for a little while. Can anyone familiar with this device driver comment. Is it also coincidentally possible that the disk starts showing its age right when I switched to current nah too much of coincidence. anyway here are the messages: Can you provide the model number and firmware revision for this drive? According to the controller, the drive is failing to respond to a whole slew of commands that we have queued to it. You might have better luck if you reduce the tag depth to the disk via camcontrol. I'm running into the same problems on a very light I/O load (running /usr/bin/less on certain files triggers it). There's also a timeout every time at bootup. I have included my dmesg below. I acquired the hardware recently (used but free). Therefore, I don't know much about it, except that some of it didn't work when I got it. Like the original poster, I have an integrated Adaptec SCSI controller (AIC-7880, BIOS rev 1.2S-HP, it says). I lack SCSI-fu, so please let me know if any additional information would be useful. I can provide access to the box to anyone interested in tracking down the problem. Timecounter i8254 frequency 1193182 Hz CPU: Pentium Pro (199.74-MHz 686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping = 9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 536870912 (524288K bytes) avail memory = 517156864 (505036K bytes) Changing APIC ID for IO APIC #0 from 16 to 2 in MP table APIC_IO: MP table broken: 8259-APIC entry missing! Changing APIC ID for IO APIC #0 from 0 to 2 on chip Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82454KX/GX (Orion) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 0.0 on pci0 isa0: ISA bus on isab0 atapci0: CMD 646 ATA controller port 0xfc00-0xfc0f,0x374-0x377,0x170-0x17f,0x3f4-0x3f7,0x1f0-0x1ff irq 14 at device 1.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xf800-0xf8ff mem 0xffdfc000-0xffdfcfff irq 9 at device 2.0 on pci0 ahc0: Using left over BIOS settings aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs fxp0: Intel Pro 10/100B/100+ Ethernet port 0xf400-0xf41f mem 0xffc0-0xffcf,0xffdec000-0xffdecfff irq 10 at device 12.0 on pci0 fxp0: Ethernet address 00:60:b0:6b:2d:1b inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: display, VGA at device 14.0 (no driver attached) pci0: memory, RAM at device 20.0 (no driver attached) orm0: Option ROMs at iomem 0xc8000-0xcc7ff,0xc-0xc7fff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) Timecounters tick every 10.000 msec APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 acd0: CDROM HITACHI CDR-8130 at ata0-slave PIO4 Waiting 15 seconds for SCSI devices to settle (probe0:ahc0:0:0:0): SCB 0x9 - timed out ahc0: Dumping Card State in Message-out phase, at SEQADDR 0x15f ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0xc0, ARG_2 = 0x2 HCNT = 0x0 SCBPTR = 0x0 SCSISEQ = 0x12, SBLKCTL = 0x0 DFCNTRL = 0x4, DFSTATUS = 0x6d LASTPHASE = 0xa0, SCSISIGI = 0xb6, SXFRCTL0 = 0xa8 SSTAT0 = 0x7, SSTAT1 = 0x3
Re: machdep.c problem
Thus spake Mitsuru IWASAKI [EMAIL PROTECTED]:
OK, it seems to be difficult to determine the region for any BIOSes.
I've decided to introduce a new loader tunable to indicate that BIOS
has broken int 12H. Attached patch back out 1.385.2.26 changes to
support older BIOSes, and add support for broken int 12 BIOSes by
new loader tunable.
I don't think this is the best solution, but it is probably good for
all people for now.
I'll make the equivalent patches for CURRENT and commit them,
then MFC soon.
Sorry for inconvenience, folks.
This approach is okay with me in the sense that it doesn't break
anything that wasn't already broken, but as you say, I think we
can do better. Below is a patch that merely extracts the basemem
size from the bootinfo structure for the purposes of mapping the
EBDA. I retained the int 12h fallback just to be safe, but I
think the bootinfo structure is initialized with a valid basemem
for all loaders since at least 1998. (Maybe the fallbacks in the
kernel should be removed entirely to avoid redundancy, or moved
from loader and boot2 to locore.s.)
I also converted basemem from kilobytes to bytes in order to
simplify the math in the common case. Patches are against
-CURRENT; I can provide patches against -STABLE as well, barring
any complaints.
Index: machdep.c
===
RCS file: /cvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.547
diff -u -r1.547 machdep.c
--- machdep.c 7 Nov 2002 23:57:16 - 1.547
+++ machdep.c 10 Nov 2002 12:09:19 -
@@ -1477,7 +1477,25 @@
bzero(vmf, sizeof(struct vm86frame));
bzero(physmap, sizeof(physmap));
- basemem = 0;
+
+ /*
+* If basemem is 640, the gap contains an extended BIOS
+* data area and must be mapped read/write before any
+* BIOS calls are made. Note that we can't use int 0x12
+* to determine the base memory at this point because
+* some modern machines do not support that interface.
+* Instead, we rely on the loader to supply the value.
+*/
+ basemem = bootinfo.bi_basemem;
+ if (basemem) {
+ for (pa = trunc_page(basemem);
+pa ISA_HOLE_START; pa += PAGE_SIZE)
+ pmap_kenter(KERNBASE + pa, pa);
+
+ pte = (pt_entry_t *)vm86paddr;
+ for (i = basemem PAGE_SHIFT; i 160; i++)
+ pte[i] = (i PAGE_SHIFT) | PG_V | PG_RW | PG_U;
+ }
/*
* map page 1 R/W into the kernel page table so we can use it
@@ -1515,6 +1533,11 @@
if (smap-length == 0)
goto next_run;
+ if (smap-base == 00 smap-length = (512 * 1024)) {
+ basemem = smap-length;
+ goto next_run;
+ }
+
if (smap-base = 0x) {
printf(%uK of memory above 4GB ignored\n,
(u_int)(smap-length / 1024));
@@ -1546,64 +1569,21 @@
next_run: ;
} while (vmf.vmf_ebx != 0);
- /*
-* Perform base memory related probes setup
-*/
- for (i = 0; i = physmap_idx; i += 2) {
- if (physmap[i] == 0x) {
- basemem = physmap[i + 1] / 1024;
- break;
- }
- }
+ if (physmap[1] != 0)
+ goto physmap_done;
- /* Fall back to the old compatibility function for base memory */
if (basemem == 0) {
vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ basemem = vmf.vmf_ax * 1024;
}
- if (basemem 640) {
+ if (basemem 640 * 1024) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
- basemem);
- basemem = 640;
+ basemem / 1024);
+ basemem = 640 * 1024;
}
/*
-* XXX if biosbasemem is now 640, there is a `hole'
-* between the end of base memory and the start of
-* ISA memory. The hole may be empty or it may
-* contain BIOS code or data. Map it read/write so
-* that the BIOS can write to it. (Memory from 0 to
-* the physical end of the kernel is mapped read-only
-* to begin with and then parts of it are remapped.
-* The parts that aren't remapped form holes that
-* remain read-only and are unused by the kernel.
-* The base memory area is below the physical end of
-* the kernel and right now forms a read-only hole.
-* The part of it from PAGE_SIZE to
-* (trunc_page(biosbasemem * 1024) - 1) will be
-* remapped and used by the kernel later.)
-*
-* This code is similar to the code used in
-* pmap_mapdev, but since no memory needs to be
-* allocated we simply change the
Re: machdep.c problem
Thus spake Mitsuru IWASAKI [EMAIL PROTECTED]: This approach is okay with me in the sense that it doesn't break anything that wasn't already broken, but as you say, I think we can do better. Below is a patch that merely extracts the basemem size from the bootinfo structure for the purposes of mapping the EBDA. I retained the int 12h fallback just to be safe, but I think the bootinfo structure is initialized with a valid basemem for all loaders since at least 1998. (Maybe the fallbacks in the kernel should be removed entirely to avoid redundancy, or moved from loader and boot2 to locore.s.) Yes, this idea was in my first patch actually, and this was not good solution as Bruce explained. Please see the archive at: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=94412+0+archive/2002/freebsd-current/20021006.freebsd-current It sounds like the basic objection is, ``We came up with this feature in 1995 and never used it, so we shouldn't start using it now.'' Fine, but I still maintain that determining the memory size in real mode like everyone else is the right thing to do. Are there any objections to the following? - Remove the redundant and unused memory detection code from boot2, loader, and libi386. - Mark the bootinfo fields bi_basemem and bi_extmem as deprecated. - Determine basemem in locore.s using 15h:e820h, with a fallback to int 12h. - Remove the basemem calculation from machdep.c. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: adaptec scsi - seagate da -- current
Thus spake David Schultz [EMAIL PROTECTED]: I'm running into the same problems on a very light I/O load (running /usr/bin/less on certain files triggers it). There's also a timeout every time at bootup. I have included my dmesg below. [...] Here's some additional information: # camcontrol inquiry da0 pass0: QUANTUM XP34550S LXY1 Fixed Direct Access SCSI-2 device pass0: Serial Number PCB=2011303002 ; HDA=184715611932 pass0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled # camcontrol tags da0 -v (pass0:ahc0:0:0:0): dev_openings 24 (pass0:ahc0:0:0:0): dev_active0 (pass0:ahc0:0:0:0): devq_openings 24 (pass0:ahc0:0:0:0): devq_queued 0 (pass0:ahc0:0:0:0): held 0 (pass0:ahc0:0:0:0): mintags 24 (pass0:ahc0:0:0:0): maxtags 32 # camcontrol inquiry da1 pass1: QUANTUM VIKING 4.5 NSE 8808 Fixed Direct Access SCSI-2 device pass1: Serial Number 174716034271 pass1: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled # camcontrol tags da1 -v (pass1:ahc0:0:1:0): dev_openings 253 (pass1:ahc0:0:1:0): dev_active0 (pass1:ahc0:0:1:0): devq_openings 253 (pass1:ahc0:0:1:0): devq_queued 0 (pass1:ahc0:0:1:0): held 0 (pass1:ahc0:0:1:0): mintags 2 (pass1:ahc0:0:1:0): maxtags 255 It seems like da0 is the problem device. Just after it times out now and then, camcontrol shows things like: # camcontrol tags da0 -v (pass0:ahc0:0:0:0): dev_openings 22 (pass0:ahc0:0:0:0): dev_active2 (pass0:ahc0:0:0:0): devq_openings 22 (pass0:ahc0:0:0:0): devq_queued 0 (pass0:ahc0:0:0:0): held 0 (pass0:ahc0:0:0:0): mintags 24 (pass0:ahc0:0:0:0): maxtags 32 # camcontrol tags da0 -v (pass0:ahc0:0:0:0): dev_openings 16 (pass0:ahc0:0:0:0): dev_active8 (pass0:ahc0:0:0:0): devq_openings 16 (pass0:ahc0:0:0:0): devq_queued 0 (pass0:ahc0:0:0:0): held 0 (pass0:ahc0:0:0:0): mintags 24 (pass0:ahc0:0:0:0): maxtags 32 It seems like da1 is fine, but then again I use that drive less heavily. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: adaptec scsi - seagate da -- current
Thus spake Andre Albsmeier [EMAIL PROTECTED]: It seems to be a Quantum Atlas drive. IIRC, I have several of them running fine (I am not 100% sure, I am on holidays at the moment :-)). You might want to check the firmware of that drive. I have upgraded the FW on my Quantum Atlas I and II drives a (long) time ago. You might want to look at ftp://ftp.quantum.com for FW upgrades. When I am back on wednesday, I can give you more info about the FW stuff. In case you want to download a new one, I have written a small tool for FreeBSD to upgrade the FW on several SCSI devices (the Quantum Atlas and Viking are supported). Thanks for the tip. I couldn't log on to ftp.quantum.com, but I found the firmware updates at ftpdownload.maxtor.com/pub/Quantum%20Products/. The update doesn't seem to have made any difference, unfortunately. *sigh* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 optimization bug ?
Thus spake TOMITA Yoshinori [EMAIL PROTECTED]: But unfortunately, that ugly code was contained in our inhouse library written by someone. It took me two days to debug and find out where difference comes from between gcc-2.95.4 and gcc-3.2.1. You can work around the problem by disabling -fschedule-insns or -fstrict-aliasing, both of which are turned on by -O2. The latter option is the more direct cause of your problem, but for some reason only the combination of the two seems to generate incorrect output on i386. Of course what you really ought to do is fix the code. C99 makes no provisions for type punning, to my knowledge. However, the GCC project officially blesses two practices: - referring to any object through a character pointer - punning the elements of a union Note that the latter only works if you directly refer to the union directly, rather than through a pointer. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel not booting....Immediate crash
Thus spake Bruce Evans [EMAIL PROTECTED]: Perhaps the problem with int 0x12 is the same as the one with int 0x15. Old implementations of int 0x12 just read the word at 0x40:0x13 in real or vm86 mode. This only requires physical page 0 to be mapped readable to work in vm86 calls. New implementations might want more. They could reasonably expect all of the first MB of physical memory to be mapped r/w into vm86 space. It's not clear that any BIOS call works in vm86 mode. BIOS calls could unreasonably expect to access all of memory as if in real mode (e.g., they could stash their variables in extended memory and use the himem hack or a switch to protected mode to access them). Could be. I would hope that mapping page 0, the BIOS data segment, and the EBDA would solve the problem, but there's still a chicken-and-egg problem with doing this in vm86 mode. I haven't heard any additional details from Iwasaki-san, but making the memory determination in vm86 mode seems fundamentally broken regardless. Also, you mentioneded earlier that Linux doesn't use int 12h anymore. But notice that they call 15:E820 in real mode, rather than turning on virtual memory and then temporarily mapping an arbitrary chunk of the first 640K of RAM. Why don't you just put the memory size detection code in locore.s? I'd be happy to help out with this, although my time is constrained after Monday. locore.s runs entirely in protected mode. It could switch between real and protected mode like the boot code does, but that would defeat the point of the (not very well designed) division of labour between the boot code and locore -- the complications for real mode are supposed to be limited to the boot code. Of course, they have been replaced by larger complications and bugs for vm86 mode :-(. More in another reply. That is why I'm surprised by your earlier post where you say that it's a bad idea to take the basemem value from the boot code. As it is, the kernel duplicates much of the memory determination code of the boot loader. I would think it could at least rely on bootinfo.bi_basemem when that field is nonzero. If these values in bootinfo are going to remain unused, they should be removed, but I think a far better solution is to start using them. In fact, the interface could be extended to pass the int 15h:e820h memory map to the kernel. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: machdep.c problem
Thus spake Bruce Evans [EMAIL PROTECTED]: I retained the int 12h fallback just to be safe, but I think the bootinfo structure is initialized with a valid basemem for all loaders since at least 1998. (Maybe the fallbacks in the Since 1995, but not in boot2 since 2002/10/01. The bi_memsizes_valid flag unfortunately covers both bi_basemem and bi_extmem, so it is still set although bi_basemem is bogus. Also, boot2 and most (all?) other places never checked for errors from int 0x12, so bi_basemem may be pure garbage. That's easy enough to fix. Add fields bi_newbasemem and bi_newextmem, implement them correctly, and fall back to the present behavior if neither are present. This approach couldn't make things any worse than they already are. IIRC, the main reason for making VM86 standard was to use it here. vm86_intcall() still doesn't seem to be used much. It is used mainly for the memsize calls and setting vesa modes. int 0x12 can be done just as easily in the boot code. Setting vesa modes can be optional. Only the memory map subcall of the int 0x15 is much easier to do like it is done now (the maps are too large for the boot code to pass easily). Linux manages this by reserving a page for the int 15h:e820h map, I think. It doesn't look unreasonably difficult to pass the map to the kernel. Even if we have to resort to VM86 for this, we can at least deal with basemem in real mode. Are there any objections to the following? [...] - Remove the basemem calculation from machdep.c. machdep.c could probably do the real mode switch without much more difficulty than boot2, etc. You think so? I would imagine that after paging is enabled, switching to real mode from a loaded kernel would be nontrivial. I would prefer to fix int 0x12 (if BIOSes are so broken as to trap even when it is set up correctly, then handle the trap and make int 0x12 return 0; also return 0 if it fails. So basemem is 0 in broken cases -- waste a whole 640K as a reward for being broken. Note that the subsequent int 0x15 call(s) in machdep.c will still work, just as if the BIOS ate the 640K -- we map it all r/w for the BIOS). Your idea sounds reasonable, although I would still prefer to fix the boot loader to reliably report the base memory size. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /dev/acd*t* no longer available in -current?
Thus spake Robert Watson [EMAIL PROTECTED]: So one thing we could start doing is have sysinstall's adduser stuff offer to place new users in the operator group, and set up the default permissions on removable devices such that the operator group has read/write access to them (or even just read-access). This would be logically equivilent to placing users in an admin group at instlal on Windows or Mac OS X. Operator access connotes the ability to shut down the system in FreeBSD, as well as the ability to dump file systems, etc. Another possibility would be to evolve our notion of console user based on fbtab some for workstation configurations. I think putting new users in the operator group, even as a default-off option, is more liberal than necessary. Using fbtab to allow access to removable and audio devices seems like the right thing to do. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Asking for tester (small patch to chown(8)/chgrp(1))
Thus spake Garrett Wollman [EMAIL PROTECTED]: I'm concerned about the used character: -r is similiar to -R Yes, `-r' would be a very poor choice for the reason you state. Agreed, but the precedent has already been set by touch(1) and truncate(1). If we're going to get it wrong some of the time, we might as well be consistent about it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Asking for tester (small patch to chown(8)/chgrp(1))
Thus spake Alexander Leidinger [EMAIL PROTECTED]: I'm concerned about the used character: -r is similiar to -R Yes, `-r' would be a very poor choice for the reason you state. Agreed, but the precedent has already been set by touch(1) and truncate(1). If we're going to get it wrong some of the time, we might as well be consistent about it. When we don't look at the fact that neither touch nor truncate operate recursivly... what about changing touch and truncate to allow the proposed -c (or -i) too and mark -r as deprecated (if it isn't covered by a standard)? Adding a uniform replacement to all three sounds good to me, as long as there isn't any standard involved. I'm a little bit suspicious given that Solaris touch(1) uses -r to mean the same thing we do. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Asking for tester (small patch to chown(8)/chgrp(1))
Thus spake Tim Robbins [EMAIL PROTECTED]: On Wed, Nov 20, 2002 at 01:27:43PM +0100, Alexander Leidinger wrote: On Tue, 19 Nov 2002 10:27:00 -0800 David Schultz [EMAIL PROTECTED] wrote: I'm concerned about the used character: -r is similiar to -R Yes, `-r' would be a very poor choice for the reason you state. Agreed, but the precedent has already been set by touch(1) and truncate(1). If we're going to get it wrong some of the time, we might as well be consistent about it. When we don't look at the fact that neither touch nor truncate operate recursivly... what about changing touch and truncate to allow the proposed -c (or -i) too and mark -r as deprecated (if it isn't covered by a standard)? I'd really rather that we didn't change this at all, even if it seems inconsistent. Changing it would just lead to more confusion. I am also against adding new options to chown to copy ownership from existing files. Copy ownership: chown `stat -f%Su file1` file2 Copy group: chgrp `stat -f%Sg file1` file2 Copy both:chown `stat -f%Su:%Sg file1` file2 These could easily be made into shell functions or whatever... Admittedly it *is* creeping featurism, but there's already creeping featurism all over the place if you're going to be that strict about it. You might as well reimplement ls(1) as a shell script and remove 30 of its 33 documented options. I think -r is a specific case that happens to be useful and convenient for chown. Most of this discussion has been bogged down in the choice of option name, which is really silly. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
Thus spake David O'Brien [EMAIL PROTECTED]: On Wed, Nov 20, 2002 at 05:57:41PM +0100, Marc Recht wrote: Hi! Will gcc 3.2.1/release be imported before 5.0R ? Just curious.. There will be no more GCC imports before 5.0-R. It is just too much code churn with too little road testing before 5.0-R. As I recall, the original plan was to import GCC 3.3 for 5.0-R. At the time, there were concerns about ABI changes between 3.2 and 3.3 that people wanted to get in before 5.0. What is the new plan? GCC 3.3 for 5.1-R? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Why isn't NOCLEAN the default? (was: Re: Cross-Development with NetBSD)
Thus spake John Baldwin [EMAIL PROTECTED]: Make release is a very poor example b/c make release goes to great efforts to create a clean-room environment for a release. make rerelease is quite helpful though and does do what you want to restart a previous release. :) Also, make buildworld -DNOCLEAN isn't too shabby, though if I could do make TARGET_ARCH=alpha everything I would prefer that. I have long wondered why NOCLEAN isn't the default. There seem to be a few cases where it doesn't DTRT for kernel builds, but it seems a bit conservative to make incremental world builds require that an undocumented variable be defined. Any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why isn't NOCLEAN the default? (was: Re: Cross-Development with NetBSD)
Thus spake Kris Kennaway [EMAIL PROTECTED]: I have long wondered why NOCLEAN isn't the default. There seem to be a few cases where it doesn't DTRT for kernel builds, but it seems a bit conservative to make incremental world builds require that an undocumented variable be defined. Any ideas? It often causes problems during upgrades (but is usually fine when just rebuilding a non-updated tree) Sounds reasonable. Maybe it should be documented in build(7), though. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc 3.2.1 release import?
Thus spake David O'Brien [EMAIL PROTECTED]: On Fri, Nov 22, 2002 at 12:46:41PM +0100, Marc Recht wrote: Don't worry about it; it's being totally blown out of proportion; No problem.. :) there's no way anyone will commit to importing a 2 day old 3.2.1, which is why I put the smiley's there. Hmm, it's a realease version. It's not the newest bleeding edge pre-release. It really comes down to a question of living with known bugs, or risking gaining a new set of unknown bugs. In theory, the set of bugs in an actual release should be smaller than the set of bugs in a prerelease. If there are still obvious problems with the prerelease we're using, importing 3.2.1 is likely to do more help than harm. But it's up to you and the RE team; I don't care as long as the compiler isn't known to generate incorrect code. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No entries in /proc :: feature or problem ??
Thus spake Robert Watson [EMAIL PROTECTED]: The reasons to deprecate procfs are many-fold -- not least that there are existing interfaces in the kernel that provide most or all of its features at a substantially lower risk. You just have to see the kernel-related security advisories for FreeBSD, Linux, Solaris, etc, over the last five years to understand why we want to turn it off if we can. :-) There has also been a concerted effort to move userland system monitoring tools away from using /dev/kvm (direct kernel memory access) and towards using the sysctl() MIB interface, reducing the level of privilege required to run the monitoring tools. By the way, what do you think is the most reasonable way to implement things like /proc/$pid/map without procfs? I don't want to use procfs if I can avoid it, but on the other hand I like some of its debugging features. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc(0) broken?
Thus spake Bruce Evans [EMAIL PROTECTED]: Er, malloc(0) is defined as returning either a null pointer or a pointer to 0 bytes of allocated space. Which one it chooses to return is implementation-defined, not undefined. C90 has a bogus requirement that the pointer for malloc(0) be unique, whatever that means. C99 only requires that the objects pointed to by the results of malloc() be disjoint, and this is satisfied by FreeBSD's behaviour of returning the same magic pointer for each instance of malloc(0). In FreeBSD, malloc(0) returns a distinct pointer each time by making a 16-byte allocation. I seem to recall that it may have returned a single magic pointer at one time, so what you say might have been correct some time ago. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Autodefaults in disklabel on 5.0dp2 install
Thus spake Garance A Drosihn [EMAIL PROTECTED]: I'm installing dp2 on a 4-gig disk. I want to split that in two, with dos for the first 2 gig and freebsd in the last 2 gig. When I got to the disklabel step, I tried the Auto Defaults option to split up the freebsd partition. It picked partition sizes of: 128 meg - / 1231 meg - swap space 208 meg - /var 208 meg - /tmp 83 meg - /usr This is a machine with 768 meg of memory, but I think the install is more likely to work with a less swapspace and something more than 83 meg for /usr. I know it's tricky to come up with an algorithm which will pick decent sizes for every combination of disk and memory sizes, but perhaps it should wire in some kind of minimum size for /usr. Also, maybe something to the effect that neither /var nor /tmp should end up larger than /usr. The algorithm could be made smarter. On the other hand, it's probably undesirable to make it so complicated that people can't fit the rules into their heads. One idea is to set up a set of linear constraints and optimize for some simple function, though even that might be overkill. At the very least, it should know when it can't find a feasible solution (``/usr can't be that small!'') and give up. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc(0) broken?
Thus spake Bruce Evans [EMAIL PROTECTED]: On Sat, 23 Nov 2002, David Schultz wrote: Thus spake Bruce Evans [EMAIL PROTECTED]: ... C90 has a bogus requirement that the pointer for malloc(0) be unique, whatever that means. C99 only requires that the objects pointed to by the results of malloc() be disjoint, and this is satisfied by FreeBSD's behaviour of returning the same magic pointer for each instance of malloc(0). In FreeBSD, malloc(0) returns a distinct pointer each time by making a 16-byte allocation. I seem to recall that it may have returned a single magic pointer at one time, so what you say might have been correct some time ago. Actually, it is correct now. malloc(0) returns the constant invalid pointer ZEROSIZEPTR (0x800 on i386's), but it returned a distinct pointer before the ZEROSIZEPTR stuff was added in rev.1.60 of libc/stdlib/malloc.c. (All this is without the malloc option V which causes malloc(0) to return a null pointer.) Aah, what I ``seemed to recall'' is actually the behavior in -CURRENT, and what I described applies to 3.X and 4.X. Thanks for the clarification. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sysinstall + swap partition requirement
Thus spake Giorgos Keramidas [EMAIL PROTECTED]: You don't *HAVE* to create a swap partition. What you see is just a warning that sysinstall prints, if you have warnings enabled in the ``Options'' menu (they are enabled by default, if I'm not mistaken in my reading of the source). I'm pretty sure it's mandatory. I recently got bitten by this bug while installing on a system with 512 MB of RAM because the drive that was to contain the swap partition (really the crash dump partition as far as I'm concerned) wasn't installed yet. I ended up not using sysinstall to do the install after all, due to other problems that were made worse by a committer who broke some of the boot code and refused to revert the changes for a number of days. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sysinstall + swap partition requirement
Thus spake Bruce Evans [EMAIL PROTECTED]: On Sun, 1 Dec 2002, David Schultz wrote: Thus spake Giorgos Keramidas [EMAIL PROTECTED]: You don't *HAVE* to create a swap partition. What you see is just a warning that sysinstall prints, if you have warnings enabled in the ``Options'' menu (they are enabled by default, if I'm not mistaken in my reading of the source). I'm pretty sure it's mandatory. I recently got bitten by this bug while installing on a system with 512 MB of RAM because the drive that was to contain the swap partition (really the crash dump partition as far as I'm concerned) wasn't installed yet. I ended It's not mandatory. I never use one on machines with sufficient RAM. How much RAM is sufficent depends on the process mix. 512MB is sufficient on my main machine since it never runs bloatware or lots of processes concurrently. I also don't use swapping (of upages -- the NO_SWAPPING option, which should be the default) or sysinstall. I meant to say that sysinstall forces you to have a swap partition, not that the kernel forces you to have one. (That would be an interesting catch-22 indeed.) It's a bug in sysinstall that you can't make it work without allocating swap space, even if you don't need it, or you don't want to add it immediately. Sorry for the confusion. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sysinstall + swap partition requirement
Thus spake Terry Lambert [EMAIL PROTECTED]: David Schultz wrote: Thus spake Bruce Evans [EMAIL PROTECTED]: On Sun, 1 Dec 2002, David Schultz wrote: Thus spake Giorgos Keramidas [EMAIL PROTECTED]: [ ... ] I meant to say that sysinstall forces you to have a swap partition, not that the kernel forces you to have one. (That would be an interesting catch-22 indeed.) It's a bug in sysinstall that you can't make it work without allocating swap space, even if you don't need it, or you don't want to add it immediately. Sorry for the confusion. On Wed, 27 Nov 2002 Giorgos Keramidas wrote: | Bearing that in mind, the change that made a swap partition | ``mandatory'' was revision 1.117 of src/usr.sbin/sysinstall/install.c Preaching to the choir, I think... this was already in this same thread, last Wednesday. Looks like nothing but rehashing, now. Yes, it *is* rehashing what was already said. Bruce's response (``it's not mandatory'') suggests that he thought we were talking about some sort of fundamental yet nonexistent problem, when in fact we were talking about a sysinstall bug. I was just clarifying. BTW, revision 1.117 was not the first revision to have this bug. That revision just made it stop bitching about partition sizes in the case where you asked it to autosize. This effectively means that there are some configurations that are permitted if you use auto defaults, and forbidden if you do things manually using sysinstall. Evil beyond words... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: swapoff code comitted.
Thus spake Christian Brueffer [EMAIL PROTECTED]: How about renaming swapon(8) into swapctl(8) after this function enhancement? This name reflects it's purpose much better and would be consistent with the other BSDs. It would be trivial to change the name, although I don't see what it buys you. NetBSD changed the name because they wanted to be able to set swap device priority and do other things through the same interface. From previous conversations, I gather that swap device priority is not a particularly desired feature for FreeBSD, and it would probably require rewriting the entire swap subsystem again in any case. Unless you intend to extend the interface further, having swapctl seems to me like changing mount/umount to mountctl. That's not to say I'm opposed to the idea, just that I don't care one way or the other. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: patch #3 Re: swapoff code comitted.
Thus spake Matthew Dillon [EMAIL PROTECTED]: :Looks good to me, modulo a few nits. I try not to nitpick, but :I've mentioned a few of them below. (BDE does a better job of it :than I do anyway. :-) : :The patch puts identical functionality in two places, so maybe it :would make sense to rip support for -s out of pstat/swapinfo (and :integrate 'pstat -ss' support into swapctl). If we really want to :go the NetBSD way, we could even integrate the swapon(2) and :swapoff(2) into swapctl(2). Doesn't matter to me. I think we should keep swapon and swapoff as separate commands. They are the most intuitive of the lot. NetBSD's pstat supports -s, as does OpenBSD's, so there is no reason to rip out support for -s in our pstat. Neither OpenBSD or NetBSD have swapinfo that I can find. We could potentially rip out the swapinfo command though all it is is a hardlink to pstat so it wouldn't really save us anything. I guess I'm just bothered by the fact that it's duplicating functionality. (In particular, the part that is duplicated was working fine in pstat and doesn't need to be on the root filesystem.) But when it comes down to it, I don't have a problem as long as other people are maintaining it. : + if (strstr(argv[0], swapon)) : + which_prog = SWAPON; : + else if (strstr(argv[0], swapoff)) : + which_prog = SWAPOFF; : :It's probably better to do a strcmp on strrchr(argv[0], '/') when :argv[0] contains a slash. Otherwise people will wonder why :swapoff(8) breaks when they (perhaps mistakenly) compile and run :it from the src/sbin/swapon directory. Hmm. How about a strstr on a strrchr. I don't like making exact comparisons because it removes flexibility that someone might want in regards to hardlinks (for example, someone might want to add a version or other suffix to differentiate certain binaries in a test environment or in an emulation environment). e.g. bsdswapon vs swapon. Isn't there a shortcut procedure to handle the NULL return case? I know there is one for a forward scan. I thought there was one for the reverse scan too. if ((ptr = strrchr(argv[0], '/')) == NULL) ptr = argv[0]; if (strstr(ptr, swapon)) ... Sounds fine. I don't know of a more concise approach offhand, and the original version used essentially what you just wrote. (I used strcmp(), so ptr had to be incremented to skip the slash.) :The repeated 'whichprog == foo' tests can be combined into a :single test at the end of the loop. They do subtly different things so I am not sure what you mean. You need to provide some code here. Yow, I didn't realize that -a and -d mean completely different things in swalctl vs swapon/swapoff. If that's how it has to work for compatibility, then it looks okay to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Thus spake Kris Kennaway [EMAIL PROTECTED]: On Mon, Dec 30, 2002 at 03:21:22AM +, Mike Barcroft wrote: === sbin/swapon cc1: warnings being treated as errors /tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist': /tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int (arg 3) Can someone please just fix this (by backing out the offending commit, if necessary)? Eek, given a 64-bit size_t, the present code leaves 32 bits of it uninitialized in the usual case. The following patch ought to fix the problem; I can't make sure right now because I'm out of town. Index: swapon.c === RCS file: /home/ncvs/src/sbin/swapon/swapon.c,v retrieving revision 1.14 diff -u -r1.14 swapon.c --- swapon.c2002/12/28 23:39:47 1.14 +++ swapon.c2002/12/30 05:15:54 @@ -211,7 +211,7 @@ size_t mibsize, size; struct xswdev xsw; int mib[16], n, pagesize; - size_t hlen; + int hlen; long blocksize; long long total = 0; long long used = 0; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Thus spake Juli Mallett [EMAIL PROTECTED]:
* De: Craig Rodrigues [EMAIL PROTECTED] [ Data: 2002-12-29 ]
[ Subjecte: Re: sparc64 tinderbox failure ]
I'm not sure if your patch will solve the problem.
The offending code is here:
240 if (lflag) {
241 char buf[32];
242 snprintf(buf, sizeof(buf), %ld-blocks, blocksize);
243 printf(%-13s %*s %*s\n,
244 Device:,
245 hlen, buf,
246 hlen, Used:);
247 }
Doesn't the printf() statement in question have the wrong number of
arguments?
No, it's using variable field-length specifiers.
Right. The complaint is that hlen is 64 bits and the printf()
expects the field length specifier to be an int. The same goes
for getbsize(hlen, ...), so I'm not sure why the compiler didn't
complain about a type mismatch. I guess it just coerced the
pointer to an int *.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Thus spake David Schultz [EMAIL PROTECTED]: Right. The complaint is that hlen is 64 bits and the printf() expects the field length specifier to be an int. The same goes for getbsize(hlen, ...), so I'm not sure why the compiler didn't complain about a type mismatch. I guess it just coerced the pointer to an int *. Aah, the compiler didn't complain because the getbsize() interface was changed between -CURRENT and -STABLE, and it now takes a 'size_t *' instead of an 'int *' to fill in with the length of the string. (To me, this change seems absolutely ridiculous, because the number in question is seldom greater than 10, much less 2^64.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aligned_nblks calculations broken in vm_swap.c
Thus spake [EMAIL PROTECTED] [EMAIL PROTECTED]: I'm actually more than a bit of mind to rip out the entire bogus swap-stripe code: If you want swap on a striped disk, you should use hardware, controller, vinum, ccd or raidframe to stripe. Ccd is a nice simple solution, but by using it you lose the ability to dynamically add and remove swap and play other tricks like swap device prioritization. (Actually, prioritization would require a better abstraction for the swap subsystem anyway.) On the other hand, the static limit on the number of devices is annoying. But the point is that the swap striping code isn't entirely redundant. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic with panic: kmem_malloc(4096): kmem_map too small...
Thus spake [EMAIL PROTECTED] [EMAIL PROTECTED]: And to that fact I have a question: At the moment 8% of the disk is reserved. It being a 170Gb raid, that wastes a good 13,6Gb, which I find at lot. tunefs lets me bring that down to 5% = 8,5Gb without speed penalty. But is for this size of spare space such a large threshold really required?? And IF i would like to experiment, where do I look for the knop to turn?? Basically you don't need to reserve anything, but as you get closer to filling the disk the time to find a free space increases rapidly and your files get very fragmented. Trouble is: they never get defragmented unless you copy them (or do a full dump/restore). I'm not sure how to nail the right number of % down, and I'm sure that both Kirk and I would like to hear your numbers :-) If someone is interested in investigating this in detail, Margo Setzer et alii did a study a few years ago on aging filesystems in order to measure fragmentation. Their intent was not to measure the effect of free space on fragmentation, but their methodology could be applied for that purpose. They happen to have a graph that suggests that large file throughput drops about 20% for a filesystem that is 75% full versus a nearly empty filesystem. http://www.eecs.harvard.edu/~vino/fs-perf/papers/sigmetrics.ps.gz I don't think you'll find that it's a good idea to have a filesystem more than 90% full. At that load factor, even a uniform hash will take on average 2.5 probes to locate free space, and performance can only exponentially decrease from there. No filesystem can avoid fragmentation and perform well without a bit of breathing room. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: update from 4.7 to 5.0
Thus spake Odhiambo Washington [EMAIL PROTECTED]: The box runs prettier, but I have some output of dmesg that I'd appreciate some explanation on. I'll mark the portions where I seek some explanation on the dmesg output itself. The most important one is with USB interfaces, because they seem to NOT start at all since updating. [...] acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% Where is that explained? I'd really love to know about it ;) That's just the ACPI driver telling you that your CPU has a reduced power (half speed) mode. My -CURRENT box doesn't support ACPI, but glancing at the code, it looks like the relevant sysctls are hw.acpi.cpu.performance_speed and hw.acpi.cpu.economy_speed. Maybe someone else can point you to some real documentation, if it's written yet. ad0: 19092MB ST320413A [38792/16/63] at ata0-master UDMA100 ad2: 9771MB Maxtor 2B010H1 [19854/16/63] at ata1-master UDMA100 Mounting root from ufs:/dev/ad0s2a lock order reversal ^^ # this is another interesting one I'd love to know about. 1st 0xc1bfb3f8 process lock (process lock) @ /usr/src/sys/kern/kern_descrip.c:2100 2nd 0xc1cf3634 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:2107 This is a known issue; see arch@, subject ``Need help fixing lock ordering with filedesc, proc and pipe.'' If you do a sysctl at just the wrong time, you could deadlock the system. The probability of this happening is on the order of one in a million, so it shouldn't be a concern to you. The warning is just pointing out that possibility so the problem can be fixed. Note that the fact that you got this warning means that you have WITNESS enabled in your kernel config, which is likely to kill performance. I don't know about the other messages, but I suspect you can safely ignore them as long as nothing is going wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: update from 4.7 to 5.0
Thus spake Terry Lambert [EMAIL PROTECTED]: David Schultz wrote: Thus spake Odhiambo Washington [EMAIL PROTECTED]: acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% Where is that explained? I'd really love to know about it ;) That's just the ACPI driver telling you that your CPU has a reduced power (half speed) mode. Can I vote for replacing enabled with available, so it does not look like it's being turned on on you, so that you have to post to this mailing list asking about it, in the future? I second that. The message caused me a double-take the first time I saw it, too. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 without swap
Thus spake Lucky Green [EMAIL PROTECTED]: I am about to set up a FreeBSD 5.0 machine without a swap partition. The server has 1GB of RAM. Are there any caveats that I need to consider during installation or configuration? If you're using sysinstall, it might insist that you have swap. Then again, that may be fixed by now. Beyond that, you won't be able to take kernel crash dumps, and you'll have to be careful that you don't run out of RAM. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 without swap
Thus spake Lucky Green [EMAIL PROTECTED]: Miguel wrote: Having no swap will prevent you from getting crashdumps in case of panic which, if you run 5.0, is not that unusual. Besides these days harddrives cost $1/GB, so why not setup the swap partition anyway? I don't want cleartext cryptographic keys to ever touch magnetic media, thus potentially opening the door to future forensic analysis. You can accomplish that by wiring the pages containing your cryptographic keys, rather than effectively wiring every page in the system by having no swap space. Alternatively, unless you're really paranoid, it's probably sufficient to write over your swap partition with random data before you shut down the system. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 64 bit quantities in statfs ?
On Mon, Aug 18, 2003, Matthew Dillon wrote: As part of the DragonFly effort we are going to increase the mount path limit from 80 chars to 1024. This will change the statfs structure. I thought I would adopt the 64 bit changes that 5.x has made to keep things synchronized. Except... there don't appear to be any 64 bit changes to struct statfs in 5.x. Am I missing something here? Is there an 'nstatfs' structure that I have not seen? The following probably need to be 64 bit entries: f_blocks f_bfree f_bavail f_files f_ffree f_syncwrites f_asyncwrites f_syncreads f_asyncreads Yep, looks broken. In the POSIX standard, the functionality of statfs() is provided by statvfs(), so implementing the latter may be a way out that doesn't involve breaking any ABIs. Unfortunately, the implementation of statvfs() in FreeBSD 5.X relies on statfs(), so it's broken despite having the correct field sizes. Moreover, statvfs() is underspecified such that it isn't actually required to do anything useful... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 64 bit quantities in statfs ?
On Mon, Aug 25, 2003, Garrett Wollman wrote: On Sun, 24 Aug 2003 16:04:40 -0700, David Schultz [EMAIL PROTECTED] said: Yep, looks broken. In the POSIX standard, the functionality of statfs() is provided by statvfs(), so implementing the latter may be a way out that doesn't involve breaking any ABIs. statfs() is a lot more useful interface than statvfs(). I'd like to keep statvfs() as the ``standard'' interface, rather than extending it to cover all of the information that statfs() has. In order to grow statfs() we need to rev libc. It might be appropriate to do that in the 5.2 time frame, if we are still anticipating that 5.2 will be the -stable crossover point. RE team? We can't fix statfs() until 6.0. statvfs() is potentially just as useful, and it doesn't suffer from the same problems. Despite being underspecified by the standard, many systems, e.g. Solaris, make it convey at least as much information as statfs(). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd
On Fri, Aug 29, 2003, Christoph Kukulies wrote: I did a cvsup and rebuild of world and ports, portupgrade, reinstalled mod_php4, apache and still get this sh apache.sh start Syntax error on line 237 of /usr/local/etc/apache/httpd.conf: Cannot load /usr/local/libexec/apache/libphp4.so into server: /usr/local/libexec/apache/libphp4.so: Undefined symbol __fpclassifyd I'm pretty sure that my binaries are in sync. A dangling libraries somewhere? Something is probably out of date, but I don't know whether it's Apache or some library that Apache depends on. It seems like you're loading a 4.X libc on a 5.X system. Try running 'ldd' on the Apache binary (not the wrapper script), and do the same for all the libraries that ldd mentions. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng panic: ata_dmasetup: transfer active on this device!
I have a machine that panics reliably within ten minutes of operation with ATAng. It subsequently locks up, so I can't obtain a dump, and I get a small amount of random filesystem corruption upon rebooting. Everything was fine with ATAog. I don't have a serial cable handy at the moment, but the DDB traceback looks like this: panic: ata_dmasetup: transfer active on this device! cpuid = 0 [...] panic [...] ata_dmastart(d3075000,4000,0,101) [...] ata_pci_dmastart(d3075000,4000,0,20) [...] ata_transaction [...] ata_start [...] ata_completed [...] taskq_run [...] [...] I can attach a serial cable and get some more information if necessary. The dual-processor machine in question has one 200GB UATA 100 drive attached to ad0 and two 36GB SATA drives on ad4 and ad6, mirrored through ccd(4). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vm_map.c LOR
On Sat, Sep 27, 2003, Florian C. Smeets wrote: Hey guys, got this one with today's current: lock order reversal 1st 0xc28008ac vm object (vm object) @ /space/src/sys/vm/vm_map.c:2195 2nd 0xc082f110 system map (system map) @ /space/src/sys/vm/vm_kern.c:328 Stack backtrace: backtrace(c037b3b0,c082f110,c0390c85,c0390c85,c0390b1a) at backtrace+0x17 witness_lock(c082f110,8,c0390b1a,148,0) at witness_lock+0x672 _mtx_lock_flags(c082f110,0,c0390b1a,148,3) at _mtx_lock_flags+0xba _vm_map_lock(c082f0b0,c0390b1a,148,c03dcfe0,2b4) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,cf083b18,c030c587) at kmem_malloc+0x3a [...] This is a false positive. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ata_dmasetup: transfer active on this device!
On Mon, Oct 27, 2003, Robert Watson wrote: Bumped into this panic on a kernel from Oct 4 running on my notebook. Unfortunately, I don't have a good trace because I didn't have access to a serial console, or a debugging kernel :-(. It might well already be fixed, but I figured I'd post about it just in case. Basically, I was shutting down my notebook, and did a shutdown -p NOW. During the shutdown, the system panicked. panic: ata_dmasetup: transfer active on this device! ... ata_dmastart+0x26 ata_pci_dmastart+0x29 ata_transaction+0x999 ata_start+0x1c9 ata_completed+0x230 taskqueue_run+... I have had this problem since the day ATAng was committed. I last verified that it was still an issue about two weeks ago, but I'm reluctant to continue testing on my main machine (the only one that triggers the bug) because it leads to random data corruption. The configuration that *consistently* produces this bug within five minutes of operation involves two 36GB SATA disks mirrored with ccd(4). My best guess is that there's a race in the ATAng code that is exacerbated by ccd(4). By brief inspection, it appears that there are a number of problems with the locking. For instance, ata_interrupt() does an ATA_UNLOCK_CH() with no matching ATA_LOCK_CH(). (This is not detected by witness because ATAng uses its own locking primitives, which have sleep/wakeup races among other things...) Unfortunately, I don't understand the code well enough to fix it and I don't have the time to understand it. If you ever find that this problem has gone away, please let me know so I can sync the ATA driver in my tree. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. This problem illustrates that we need to be careful as we roll forward support for C99 features that cannot be implemented as regular functions, but that are regular functions in C89. I expect that once all that support is in the tree, we can do a single libm version number bump and remove the compatibility hacks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Fri, Oct 31, 2003, John Angelmo wrote: But still after importing e_scalb.c or e_scalbf.c and rebuilding gives me this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 Sounds like you might have accidentally imported e_scalbf.c twice---once as e_scalbf.c and once as e_scalb.c. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CSTD=c99 breaks package creation
On Thu, Jun 12, 2003, Tim Robbins wrote: On Wed, Jun 11, 2003 at 07:37:01PM -0700, Kris Kennaway wrote: It's possible that there's either a bug in gcc or there is C code in the system that has a different meaning when interpreted to C99 standards. I think I may have found the problem, and I think it's in GNU tar. GNU tar does this: #ifndef __attribute__ /* This feature is available in gcc versions 2.5 and later. */ # if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 5) || __STRICT_ANSI__ # define __attribute__(Spec) /* empty */ # endif #endif machine/_types.h does this: typedef int __attribute__((__mode__(__DI__))) __int64_t; typedef unsigned int __attribute__((__mode__(__DI__))) __uint64_t; If __attribute__ is empty, __int64_t becomes a synonym for int. Bad. Wow! Nice catch... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems tuning kmem_map on 5.1-REL box.
On Tue, Jun 17, 2003, Peter Losher wrote: Hi - If this sort of question is better asked on a more specialized list @freebsd.org, please let me know. (Since 5.1 is still considered a developmental release, one doesn't know if either -current or -stable would be more appropriate. So I am sending it to -current. So, I recently put a Quad-Xeon server (w/ 4GB of RAM) into production as primarily as a master FTP server for ISC as well as for FreeBSD (US/IPv6 side of ftp.freebsd.org). All has been going well for the past couple of weeks until 5.1 was released. Traffic spiked, and the server started panicking every 12 hours: panic: kmem_malloc(4096): kmem_map too small: 377487360 total allocated So after looking at the archives, I read that FreeBSD had issues with installed memory above 2GB, so I set the sysctl kern.maxvnodes=13, but to no effect: panic: kmem_malloc(16384): kmem_map too small: 293519360 total allocated I have since removed my NMBCLUSTER setting in the kernel, so it would be set automatically, I have even set VM_KMEM_SIZE_SCALE=2 (I haven't messed with the other KMEM kernel options, as I was hoping to avoid it) And a couple of hours ago I updated the kernel with the latest kern_malloc.c file in the RELENG_5_1 branch. To allow the kmem_map to exceed 200 MB, you'll also need to tweak VM_KMEM_SIZE_MAX to (for example) '(1024 * 1024 * 1024)'. BTW, the formula, which I stole from vmparam.h, is: min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), VM_KMEM_SIZE_MAX) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems tuning kmem_map on 5.1-REL box.
On Thu, Jun 19, 2003, Peter Losher wrote: On Wed, 18 Jun 2003, David Schultz wrote: To allow the kmem_map to exceed 200 MB, you'll also need to tweak VM_KMEM_SIZE_MAX to (for example) '(1024 * 1024 * 1024)'. BTW, the formula, which I stole from vmparam.h, is: min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), VM_KMEM_SIZE_MAX) Looks like I may have found some kind of error, adding this to my kernel config: # KVM options VM_KMEM_SIZE_SCALE=4 options VM_KMEM_SIZE_MAX=(1024 * 1024 * 1024) (1024MB of KVM, 4096MB/4, 1024MB MAX KVM size) Cause the following warning and compile bomb: % config KVM_FIX WARNING: unknown option `*' removed from ../compile/KVM_FIX/opt_vm.h This looks like a limitation of config(8). Changing the options to: # KVM options VM_KMEM_SIZE_SCALE=4 options VM_KMEM_SIZE_MAX=(1024*1024*1024) Configs and compiles cleanly, but panics when rebooting with the new kernel: kmem_suballoc: bad status return of 3. panic: kmem_suballoc That means there wasn't a large enough contiguous region for the kmem_map. I guess I forgot to tell you that you also need to adjust KVA_PAGES upwards so that the kernel has enough virtual address space to fit the map. The following should do: options KVA_PAGES=512 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: write access to dos partition hangs system completely
On Sun, Jun 15, 2003, Andreas Klemm wrote: FreeBSD titan.klemm.apsfilter.org 5.1-RC FreeBSD 5.1-RC #0: Sun Jun 1 14:21:32 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN5 i386 When I mount my dos partition read write and copy some data to it it immediately freezes the system. [...] da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 Mounting root from ufs:/dev/ad2s2a ad0: hard error cmd=read fsbn 115471868 of 115471868-115471871 status=51 error=40 pid 640 (squid), uid 65534: exited on signal 6 pid 674 (squid), uid 65534: exited on signal 6 pid 676 (squid), uid 65534: exited on signal 6 pid 678 (squid), uid 65534: exited on signal 6 pid 680 (squid), uid 65534: exited on signal 6 ad0: hard error cmd=read fsbn 115471868 of 115471868-115471871 status=51 error=40 ad0: hard error cmd=read fsbn 115471871 status=51 error=40 ad0: hard error cmd=read fsbn 115471868 of 115471868-115471871 status=51 error=40 ad0: hard error cmd=read fsbn 115471871 status=51 error=40 I don't know which of these devices your DOS partition is on, but the root problem seems to be the hardware. That said, msdosfs does hang when a write error occurs, so that may be your problem. (It gets into a loop in which it retries forever.) I submitted kern/37035 regarding this over a year ago, although I don't know to what extent the original problem or the trivial patch I posted still apply to 5.X. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions about VM_KMEM_SIZE_SCALE
On Tue, Jun 24, 2003, Jay Kuri wrote: Hi there, Can anyone shed some light on the implications of adjusting VM_KMEM_SIZE_SCALE? In particular I'm wondering if I increase this to, say, 2, what happens? I must admit I don't know how KVA is different from KVM or total RAM... so the note in kern_malloc (on an x86 with 256M KVA, try to keep VM_KMEM_SIZE_MAX at 80M or below) doesn't shed enough light on the matter. What are the implications of VM_KMEM_SIZE getting large? Does changing this affect memory available to user programs if it's unused by the kernel? No, KVA_PAGES affects the memory available to user programs. (You have a 4 GB address space on i386 to split between user programs and the kernel.) Within the kernel's share of this address space, memory is split into submaps, such as the mb_map (for the network), buffer_map for the filesystem buffer cache, and the kmem_map for just about everything else. These submaps are size-limited to prevent any one of them from getting out of hand. The vm_kmem_map is sized automatically based on the amount of memory you have. Specifically, kmem_map_size = min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), VM_KMEM_SIZE_MAX) The default value for VM_KMEM_SIZE_SCALE is 3, and the default VM_KMEM_SIZE_MAX is 200MB. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hyperthreading
On Fri, Jun 27, 2003, Brooks Davis wrote: On Fri, Jun 27, 2003 at 06:39:12PM -0500, Glenn Johnson wrote: Thanks. I had read the smp manual page. I know _how_ to enable HTT; I was wondering whether I _should_ enable it. It seems the answer is that it is not beneficial in its current state because the scheduler does not yet differentiate between physical and logical processors. It's more complicated then that. For many users, it's true that HTT is not useful due to the scheduling issues, but for some applications where you keep all the CPUs busy, it does help. Somewhat suprisingly, [EMAIL PROTECTED] performs better with HTT enabled then without. The individual workunits take longer to process, but the overall throughput is better (4 workunits every 6hrs instead of 2 workunits every 4hrs). Hyperthreading will generally give you better thoughput because you get better utilization of the hardware; when one functional unit would normally be idle due to a pipeline bubble, the other logical CPU may be able to provide work for it. On the other hand, as you observe, latency is worse. In particular, if you're running a web browser on one processor, it's competing for resources with your [EMAIL PROTECTED] client on the other processor, even though the [EMAIL PROTECTED] client is niced. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: new KSE signal code
On Sat, Jun 28, 2003, David Xu wrote: I begin to commit KSE signal code, libkse will be broken for a while. Umm...if it's known to be broken, then why did you commit it? If you want people to test KSE and report bugs, the version in the tree needs to be of consistently good quality. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: new KSE signal code
On Sat, Jun 28, 2003, Julian Elischer wrote: he means that between the time the commits start and finish there may be an inconsistant period.. Why is everyone so eager to jump down everyone else's throat these days? The statement that ``libkse will be broken for a while'' gave me the impression that it would be broken for a couple of days, not a couple of minutes, and I was just in the process of upgrading before trying to diagnose a signal problem involving Java. I apologize for the misinterpretation. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: new KSE signal code
On Sat, Jun 28, 2003, David Leimbach wrote: Because we aren't working on anything and need something to do... so we find ways to think about how we can enforce quality without understanding how stuff works first maybe? Umm...no, but thanks for the insult. How about: Because we are working at 3 AM to figure out why signals aren't getting delivered to java properly and we see an email saying that things will be more broken ``for a while'' and misinterpret what ``for a while'' means in this context. See previous post. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP page update
On Tue, Jul 15, 2003, Alp ATICI wrote: I was wondering whether the SMPng page at http://www.freebsd.org/smp is updated as those features are added. Because it seems like no feature update for long. For instance is the preemptible kernel going to be a part of 5.x series or going to be left to 6.x? The kernel has been preemptible for a long time. I don't know anything about the webpage. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [-CURRENT tinderbox] failure on sparc64/sparc64
On Thu, Jul 17, 2003, Dag-Erling Smorgrav wrote: On Thu, Jul 17, 2003 at 09:58:10AM +0200, Harti Brandt wrote: I have no idea how a program can core in vfork(). Probably a vm problem? Most likely a KSE-related problem in vfork(). Try replacing vfork() with fork() in make(1) and see if the problem goes away. Warning: build times may increase significantly... I would guess that the problem doesn't occur in the vfork() call itself, but in the child process (gzip?), and there's a problem that causes the child to be incompletely divorced from the parent. Is there any trick to reproducing this problem? I just did a make universe on i386 and didn't see it, but maybe my sources are too old. It would be interesting to see if fork() fixes the problem. With the VM optimizations, vfork() is only about 20% faster than fork(), so build times shouldn't be significantly impacted. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible unionfs bug
On Sun, Jul 20, 2003, Divacky Roman wrote: Hi, I might be wrong but this: free(mp-mnt_data, M_UNIONFSMNT); /* XXX */ mp-mnt_data = 0; seems to me wrong and might cause crashes etc. am I correct or wrong? its from union_vfsops.c:384 What's wrong with it? It's just freeing the memory it allocated earlier. FFS does the same thing. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: maildir with softupdates
On Wed, Jul 23, 2003, Attila Nagy wrote: Hello, Is this statement still valid? ext3 is unsafe for maildir, and with softupdates, so is ffs. http://www.irbs.net/internet/postfix/0202/0358.html The statement is FUD; this is a topic that mailer people love to complain about. It's only true if your MTA doesn't call fsync() when it wants to guarantee that the file it just wrote is on stable storage. Most filesystems don't guaranteed 100% synchronous semantics for regular data unless you ask for them explicitly, due to the performance implications. The statement you quote used to be true for ext3 due to an inadequacy in its fsync() implementation, and I'm not sure if that was ever fixed. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfprintf() has a 4096-byte memory leak?
On Sat, Aug 02, 2003, Ryan T. Dean wrote: Poul-Henning Kamp wrote: In message 3F2B9C59.3060209 at cytherianage.net http://lists.freebsd.org/mailman/listinfo/freebsd-current, Ryan T. Dean writes: /Hey all- / /I was doing some app debugging tonight, and noticed what appears to / /be a memory leak in vfprintf(). / This is probably the buffer which stdio uses for all I/O. Try calling setbuf(stdout, NULL); setbuf(stderr, NULL); as the very first thing in your program, and you will probably see that it does not allocate the 4k buffer, you may also be able to measure the performance change due to this. In other words, what you see is perfectly normal, and to be expected, but if it is a problem for you, the above is the workaround. Aha. setbuf(stdout, NULL); does prevent the buffer from being allocated. However, in the case of stdout and stderr, if you don't setbuf() it to null, a buffer is malloc'd. The corresponding free() is in fclose. So, if you [f]printf() to stdout/stderr, and fclose(stdout/stderr), you are fine. If, however, you don't know that buffers are being allocated for stdin/stdout and don't fclose() or setbuf() to NULL, a 4096-byte chunk of memory is allocated and never freed. For shits and giggles, I checked a DeadRat 8 box - no buffering by default. I guess the only reason I'm worried is the potential number of programs in the ports tree originally written on a system where stdout/stderr behave differently, or people (like myself) who didn't have a clue any sort of output buffering was enabled on stdout/stderr, and as a result have memory leaks. If the porter did their job, it shouldn't be an issue (was caught, patched, and the patch submitted upstream), but, then, we never know, right? stdio's buffering routines make a one-time allocation for their buffers, and this memory does not get freed because it can potentially get used during the entire time the program is running. This isn't a bug. See the archives for details. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: warnpassword and warnexpire in 5.1 login.conf
On Sat, Aug 02, 2003, Mats Larsson wrote: Hello! Tried this question to the questions list with no response, perhaps current is the correct list for questions related to 5.1-RELEASE?? I am trying to use warnexpire and warnpassword in login.conf but with no result, are the warnexpire and warnpassword still used in 5.1 or have they been superseded with a PAM module in the same way as minpasswordlen and minpasswordcase?? They're part of the pam_unix PAM module now, but they should still work. I tried them a few months ago, and I don't remember any special steps being necessary. You ran cap_mkdb(1), right? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: warnpassword and warnexpire in 5.1 login.conf
On Tue, Aug 05, 2003, Mats Larsson wrote: Sure, run cap_mkdb on every edit on login.conf The values im trying to use there are the following: :warnexpire=28d:\ :warnpassword=14d:\ And with pw i use the following to test with: (also with -e option) pw usermod user -p +10d The only thing im getting now is i warning in messages when i try to login into a locked account. Aug 5 12:14:39 marvin sshd[55256]: error: PAM: user accound has expired This looks reasonable. And the following varning when password is old: Aug 5 12:27:38 marvin sshd[55386]: error: PAM: OK Aug 5 12:27:40 marvin sshd[55390]: fatal: PAM: chauthtok not supprted with privsep Is there perhaps a better PAM way of doing this things now?? Hmm... Apparently you can't change an expired password with a privilege-separated OpenSSH. I don't know whether that can be fixed, but perhaps des@ has some insight. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: background fsck did not create lost+found
Thus spake Jan Srzednicki [EMAIL PROTECTED]: This massive disk mangling occured on /usr, but still, one file in /home got lost - which happened to be quite important file. Background fsck logged: Jan 20 16:06:30 stronghold root: /dev/ad1s1d: UNREF FILE I=1723065 OWNER=winfried MODE=100644 Jan 20 16:06:30 stronghold root: /dev/ad1s1d: SIZE=23397 MTIME=Jan 20 15:57 2003 (CLEARED) Jan 20 16:06:30 stronghold root: /dev/ad1s1d: Reclaimed: 0 directories, 8 files, 16439 fragments Jan 20 16:06:30 stronghold root: /dev/ad1s1d: 33802 files, 13109700 used, 6310697 free (11577 frags, 787390 blocks, 0.1% fragmentation) First two entries clearly correspond to the missing file, which should have been put in /home/lost+found. But, the poroblem is that no lost+found directory was created, while it should (as fsck_ffs(8) says). I guess its a bug, probably in the background fsck code. Still, is there any way to reclaim the file now, besides running strings(1) on the whole partition? Consider what happens when you remove a large directory tree. Thousands of directory entries may be removed, but in the softupdates case, the inodes will stick around a bit longer. The same also applies to files that have been intentionally unlinked but are still open. To avoid a syndrome where all these thousands of files end up in lost+found after a crash or power failure, fsck just removes them on softupdates-enabled filesystems. Unfortunately, this means that a newly-created file that has an inode but no directory entry will also be cleared. In some sense, this race is equivalent to the situation where something went wrong before the inode could be written. However, when you are saving a new version of an important file, you need to be careful that the new version (and its directory entry) hits the disk before the old one goes away. I know that vi saves files in a safe way, whereas ee and emacs do not. (Emacs introduces only a small race, though.) Also, mv will DTRT only if the source and destination files live on the same filesystem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
Thus spake Matthew Dillon [EMAIL PROTECTED]:
:However, when you are saving a new version of an important file,
:you need to be careful that the new version (and its directory
:entry) hits the disk before the old one goes away. I know that vi
:saves files in a safe way, whereas ee and emacs do not. (Emacs
:introduces only a small race, though.) Also, mv will DTRT only if
:the source and destination files live on the same filesystem.
:
I think you have that reversed. vi just overwrites the destination
file (O_CREAT|O_TRUNC, try ktrace'ing a vi session and you will see).
I believe emacs defaults to a mode where it creates a new file and
renames it over the original.
This means that there is a period of time where a crash may result in
the loss of the file if the vi session cannot be recovered (with vi -r)
after the fact.
vi writes and fsyncs a recovery file when it opens a file for
editing, and it fsyncs the real file before removing the recovery
file. (I don't know how reliable vi's recovery mechanism is
because I don't use vi, but at least it's ensuring that the
recovery file is written to disk when it should be.)
In Emacs, if 'make-backup-files' is non-nil (the default), the
original file ${FILE} is renamed to ${FILE}~. Then it writes out
and fsyncs a new file, which is perfectly safe. If
'make-backup-files' is nil, emacs simply omits the renaming part,
unsafely overwriting the original file. The behavior in the
latter case appears to be a bug, or at least an undocumented
feature. Emacs even causes data loss in this case when the disk
fills up! It needs to either do an fsync/rename or write and
fsync a backup file for the duration of the save.
Lastly, with ee, there's no backup file and no fsync.
Some ktrace snippets are below.
3662 vi CALL open(0x808e260,0x2,0x180)
3662 vi NAMI /var/tmp/vi.recover/vi.HjDlgO
3662 vi RET open 4
...
3662 vi CALL write(0x4,0x809a01c,0x400)
3662 vi GIO fd 4 wrote 1024 bytes
[...]old contents[...]
...
3662 vi CALL fsync(0x4)
3662 vi RET fsync 0
...
[I edit the file from old contents to new contents]
...
3662 vi CALL open(0x8095140,0x601,0x1b6)
3662 vi NAMI foo
3662 vi RET open 7
...
3662 vi CALL write(0x7,0x80bb000,0xd)
3662 vi GIO fd 7 wrote 13 bytes
new contents
3662 vi RET write 13/0xd
...
3662 vi CALL fsync(0x7)
3662 vi RET fsync 0
3662 vi CALL close(0x7)
3662 vi RET close 0
...
3662 vi CALL lseek(0x4,0,0x400,0,0)
3662 vi RET lseek 1024/0x400
3662 vi CALL write(0x4,0x809a01c,0x400)
3662 vi GIO fd 4 wrote 1024 bytes
[...]new contents[...]
...
3662 vi CALL fsync(0x4)
3662 vi RET fsync 0
[The following bit only happens if make-backup-files is non-nil]
3799 emacsCALL rename(0x848c328,0x848fba8)
3799 emacsNAMI /home/test/foo
3799 emacsNAMI /home/test/foo~
3799 emacsRET rename 0
...
[This part happens unconditionally]
3799 emacsCALL open(0x848c328,0x601,0x1b6)
3799 emacsNAMI /home/test/foo
3799 emacsRET open 3
3799 emacsCALL write(0x3,0xbfbfae24,0x3)
3799 emacsGIO fd 3 wrote 3 bytes
new
3799 emacsRET write 3
3799 emacsCALL write(0x3,0xbfbfae24,0x9)
3799 emacsGIO fd 3 wrote 9 bytes
contents
3799 emacsRET write 9
3799 emacsCALL fsync(0x3)
3799 emacsRET fsync 0
3799 emacsCALL close(0x3)
3799 emacsRET close 0
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: current- and BSD related stupid question
Thus spake Harald Schmalzbauer [EMAIL PROTECTED]: With 4.x I had a /etc/make.conf where I could force gcc to optimize for my CPU with -march. This file (/etc/defaults/make.conf) vanished, but I can see something similar now without any rule set. Does gcc (or any compiler stage like preprocessor) analyze the current building system?? Just for interest; I don't have any problems but there are quiet a few things under 5.0 which are completely new to me and I'd like to keep in touch with this great OS. What used to be /etc/defaults/make.conf is now /usr/share/examples/etc/make.conf. It works just as it always has. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: background fsck did not create lost+found
Thus spake Garrett Wollman [EMAIL PROTECTED]: On Wed, 22 Jan 2003 11:14:47 +0100 (CET), Jan Srzednicki [EMAIL PROTECTED] said: Would that be a big problem to allow some fsck option not to erase all these softupdates-pending inodes, but to put them in lost+found as usual? It certainly couldn't be done with the background fsck, because background fsck works on a snapshot and not the running filesystem; thus, it cannot make any allocations -- it can only deallocate things. Actually, that should work just fine. When background fsck notices an unreferenced inode in the snapshot, it could create a file in the underlying filesystem. The easy way to do this is to copy the data with the standard open(2)/write(2)/close(2) interfaces. After the copy, the original data blocks are deallocated as usual. A more efficient implementation might require a special kernel interface that creates a directory entry, given an inode number and path. Unfortunately, I think it is possible that the unreferenced inode has not been initialized, even though it is allocated in the inode bitmap, so you could potentially get random junk. Such a feature sounds reasonable, although I'm not sure how useful it would really be. If you have software that introduces a race window where you can lose data because it does updates incorrectly, hacking the operating system to make the race window slightly smaller is not the best solution. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I've just had a massive file system crash
Thus spake Greg Lehey [EMAIL PROTECTED]: I've been thinking about what happened, and I have a possibility: the session before shutdown included a lot of writing to that file system, and I did a shutdown -p. It's possible that the shutdown powered off the system before the disk had flushed its cache. For the moment I'm avoiding shutdown -p, but when I get home I'll try to provoke it again. FreeBSD's ``fix'' for this problem is the same as Windows 98's. Specifically, there is a 5-second delay (tuneable: kern.shutdown.poweroff_delay) after all buffers are flushed but before the power is cut. Maybe we ought to be sending FLUSH CACHE commands to all drives and waiting for them to finish. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I've just had a massive file system crash
Thus spake Nate Lawson [EMAIL PROTECTED]: On Fri, 24 Jan 2003, David Schultz wrote: Thus spake Greg Lehey [EMAIL PROTECTED]: I've been thinking about what happened, and I have a possibility: the session before shutdown included a lot of writing to that file system, and I did a shutdown -p. It's possible that the shutdown powered off the system before the disk had flushed its cache. For the moment I'm avoiding shutdown -p, but when I get home I'll try to provoke it again. FreeBSD's ``fix'' for this problem is the same as Windows 98's. Specifically, there is a 5-second delay (tuneable: kern.shutdown.poweroff_delay) after all buffers are flushed but before the power is cut. Maybe we ought to be sending FLUSH CACHE commands to all drives and waiting for them to finish. da(4) does a SYNC CACHE (see daclose() and dashutdown()). Good. I was referring to IDE in this case, because I assume that's what Greg's laptop uses. The ATA driver flushes the cache when the device is closed, but I don't think that happens during shutdown. It probably needs to register a shutdown hook like the SCSI driver. Also, the driver is a bit optimistic about how long the flush will take; it times out after 5 seconds, whereas the ATA spec says a flush can take up to 30 seconds. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH]: newfs(8) FS_OPTSPACE vs FS_OPTTIME bug
Thus spake Maxim Konovalov [EMAIL PROTECTED]: newfs(8) incorrectly claims that FS_OPTTIME is unavailable when minfree is less than MINFREE. MINFREE is defined in ufs/ffs/fs.h: #define MINFREE 8 But relevant code in ufs/ffs/ffs_alloc.c uses hardcoded value: 288 if (fs-fs_minfree = 5 || 289 fs-fs_cstotal.cs_nffree 290 (off_t)fs-fs_dsize * fs-fs_minfree / (2 * 100)) 291 break; 292 log(LOG_NOTICE, %s: optimization changed from SPACE to TIME\n, tunefs(8) metions 5% too. The code you quote in ffs_alloc.c doesn't do what you think it does. The minfree comparison there is an exception to the rule ``if there is too much fragmentation, switch optimization from space to time''. The kernel must do this because the calculation on lines 289 and 290 doesn't work very well if minfree is small. The code in newfs works in the opposite direction: it forces optimization from time to space if minfree is too small (8%). The rationale here is different: if you set minfree very low, you must expect space to be very tight, so the filesystem should optimize from space from the start. So these numbers are different on purpose, because they address separate issues. The tunefs(8) comment you refer to seems to have been introduced in rev. 1.2 of tunefs.8. I revised the comment in rev. 1.18, but even then I didn't catch the error. I think we need to s/of 5% and less/below the default value/. The manpage should also point out that the time/space optimization restrictions based on minfree are enforced by newfs/tunefs when minfree is changed, and not by the kernel. They can be overridden by subsequently asking for space or time optimization again. Also, newfs does not match tunefs exactly in its treatment of minfree. Tunefs will additionally force time optimization if minfree is = the default. Early comments in CVS logs seem to indicate that tunefs's behavior was the intended one. **OR** Here is another idea: rip out of tunefs and newfs the magic that forces space/time optimization. Instead, when someone tries to specify a small value for minfree, just warn them why they shouldn't do that. The one bit of minfree magic in ffs_alloc.c stays because it's important. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I've just had a massive file system crash
Thus spake Greg Lehey [EMAIL PROTECTED]: I've been thinking about what happened, and I have a possibility: the session before shutdown included a lot of writing to that file system, and I did a shutdown -p. It's possible that the shutdown powered off the system before the disk had flushed its cache. For the moment I'm avoiding shutdown -p, but when I get home I'll try to provoke it again. Just a heads up: Soeren tells me he will commit a fix for this in his next ATA meta-commit. I have patches if wanted. I still can't figure out why the problem would trash your entire home directory, though. Even if the disk reordered writes and failed to write some sectors, directory entries that were not being actively modified shouldn't have become corrupted, as far as I know. (Maybe your disk does track-at-once writes and just happened to be flushing the last few sectors from its cache when the power was cut.) Perhaps someone could ask Kirk, although it may take an actual hosed filesystem to diagnose what happened. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: boot delay when testing for ata devices
Thus spake Enache Adrian [EMAIL PROTECTED]:
FreeBSD used to have an irritating boot delay in 4.4. It was gone in
~4.6, never reappeared in -STABLE, but is there in -CURRENT.
(I've seen it also mentioned in some vmware documentation).
Applying this patch fixes it:
--- /arc/freebsd/src/sys/dev/ata/ata-all.cSun Jan 19 23:54:13 2003
+++ sys/dev/ata/ata-all.c Mon Jan 27 21:02:34 2003
@@ -514,7 +514,7 @@
/* apparently some devices needs this repeated */
do {
- if (ata_command(atadev, command, 0, 0, 0, ATA_WAIT_INTR)) {
+ if (ata_command(atadev, command, 0, 0, 0, ATA_IMMEDIATE)) {
ata_prtdev(atadev, %s identify failed\n,
command == ATA_C_ATAPI_IDENTIFY ? ATAPI : ATA);
free(ata_parm, M_ATA);
I'm not familiar with the ata code, but I can't see from ata-all.c
which harm this could cause.
There is already at least one person for whom this code doesn't
work, so this patch doesn't seem like a good idea. Someone needs
to figure out exactly what delays are needed here to make
everyone's hardware actually work.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: add ext2fs to the module list in modules/Makefile
Thus spake Juli Mallett [EMAIL PROTECTED]: * De: Max Khon [EMAIL PROTECTED] [ Data: 2003-01-27 ] [ Subjecte: Re: add ext2fs to the module list in modules/Makefile ] hi, there! On Tue, Jan 28, 2003 at 12:40:12AM +0200, Enache Adrian wrote: On Mon, Jan 27, 2003 at 01:36:35PM -0800, Steve Kargl wrote: Portions of the ext2fs source are covered by the GPL. You need to rebuild the kernel with option EXT2FS. The FreeBSD cannot create a ext2fs.ko and comply with the GPL. This is weird. Builting it as part of kernel is ok, but separate, as a module isn't. IIRC NetBSD has BSD-copyrighted ext2fs implementation Closely tied to their VFS implementation, which is different, of course, last I heard it was a fairly heavy task to port it, but something a lot of people would like to see. Does it work any better/worse than FreeBSD's implementation? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Christopher Vance [EMAIL PROTECTED]:
On Wed, Jan 29, 2003 at 10:35:40PM -0500, Garance A Drosihn wrote:
: How about requiring the user to touch some file in / or /boot which
: indicates the branch-tag that's acceptable for installworlds? Then
: you just need to propagate the tag from the 'cvs co' stage to some
: file under /usr/src (such as /usr/src/CVS/Tag ).
Some of use cvsup and won't have CVS/Tag.
OT: Is there a good way to get the CVS metadata in /usr/src and
/usr/ports without transferring the entire source tree over the
network? On some machines, I'd like to be able to do a CVS
{diff,log,update} now and then, but I don't have the disk space
for the entire repository. I usually end up blowing away /usr/src
and fetching a new copy from a CVS server, but I'm sure this is
far from ideal for the people who pay for that server's bandwidth.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Steve Kargl [EMAIL PROTECTED]:
On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
OT: Is there a good way to get the CVS metadata in /usr/src and
/usr/ports without transferring the entire source tree over the
network? On some machines, I'd like to be able to do a CVS
{diff,log,update} now and then, but I don't have the disk space
for the entire repository. I usually end up blowing away /usr/src
and fetching a new copy from a CVS server, but I'm sure this is
far from ideal for the people who pay for that server's bandwidth.
anoncvs
See the handbook for info.
That's a great answer...to a different question. ;-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Mike Makonnen [EMAIL PROTECTED]: Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. That's a pretty good solution, and I use those occasionally. It would be a perfect solution if there were an 'rupdate', so I don't have to (cd /tmp; cvs co src/file/i/want.c) cp /tmp/src/file/i/want.c /where/i/want/it rm -rf /tmp/src all the time. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Christopher Vance [EMAIL PROTECTED]:
On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote:
: On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote:
: Thus spake Steve Kargl [EMAIL PROTECTED]:
: On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
:OT: Is there a good way to get the CVS metadata in /usr/src and
:/usr/ports without transferring the entire source tree over the
:network? On some machines, I'd like to be able to do a CVS
:{diff,log,update} now and then, but I don't have the disk space
:for the entire repository. I usually end up blowing away /usr/src
:and fetching a new copy from a CVS server, but I'm sure this is
:far from ideal for the people who pay for that server's bandwidth.
:
:
: anoncvs
:
: See the handbook for info.
:
: That's a great answer...to a different question. ;-)
:
: It's the correct answer. I assumed that you knew
: how to use cvs.
cvsup gets me everything I need to track and compile both current and
stable.
I don't want to be forced into using cvs when there's a better tool
available (for some definition of better). I get paid to use cvs at
work, and that's how I know to choose something else...
For a while, I used to grab the whole repo (with cvsup), and used cvs
to get current and stable out of it, but now I consider that a waste
of space/time, and have reverted to just using cvsup to get the tags I
want.
I'm not a FreeBSD developer, and very rarely (just a handful of times)
have had to modify existing stuff to do what I want, so I don't need
my own repo to commit to. With that, disappers any need to use cvs.
Perhaps you can explain why cvsup is the wrong answer...
I don't know about Steve, but cvsup is the wrong answer for me
because it's a mirroring tool and not a version control tool.
Among the things I would like to do are:
- Update to a specific version of a specific file from the
repository.
- Generate a diff between two revisions in the repository,
or between a version in the repository and some local
patches of my own.
- View logs for particular files.
I asked the question in hopes that there would be some neat
feature of cvsup that mocked up some CVS metadata for me, but
since nobody has mentioned any such thing, I guess I'm out of
luck. Mirroring the entire repository is not an option on
machines with less than 6 GB of spare disk.[1] Transferring the
entire source tree over the network via anoncvs is suboptimal when
all I really want is a few kilobytes of 'CVS' subdirectories.
But I guess it will have to do for now.
[1] When the system is an aging dual PPro or 200MHz Alpha using
SCSI, buying new drives is not practical.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Ruslan Ermilov [EMAIL PROTECTED]: On Thu, Jan 30, 2003 at 09:58:15PM -0800, David Schultz wrote: I don't know about Steve, but cvsup is the wrong answer for me because it's a mirroring tool and not a version control tool. Among the things I would like to do are: - Update to a specific version of a specific file from the repository. - Generate a diff between two revisions in the repository, or between a version in the repository and some local patches of my own. - View logs for particular files. I asked the question in hopes that there would be some neat feature of cvsup that mocked up some CVS metadata for me, but since nobody has mentioned any such thing, I guess I'm out of luck. Mirroring the entire repository is not an option on machines with less than 6 GB of spare disk.[1] Transferring the entire source tree over the network via anoncvs is suboptimal when all I really want is a few kilobytes of 'CVS' subdirectories. But I guess it will have to do for now. [1] When the system is an aging dual PPro or 200MHz Alpha using SCSI, buying new drives is not practical. Well then learn how to use anoncvs? I use anoncvs. My question was, given a source or ports tree without any CVS metadata, is there a way to obtain the tiny corresponding CVS/Entries and CVS/Repository files without checking out an entirely new copy of the tree via a busy, often overloaded, anoncvs server. Keep in mind that I'm not asking a ``can it be done?'' question. I've been doing it for years. Rather, I'm asking, ``can it be done more efficiently?'' So far, the best answer I've received is ``mirror the repository locally'' (thank you, David), which I already do on one machine to maintain a local branch and will consider doing on others. I have also considered writing a script to parse embedded $FreeBSD$ tags out of source files and mock up a CVS/Entries and CVS/Repository based on that information. Perhaps I will try that and see if it works passably well. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Giorgos Keramidas [EMAIL PROTECTED]: On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote: Thus spake Mike Makonnen [EMAIL PROTECTED]: Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. That's a pretty good solution, and I use those occasionally. It would be a perfect solution if there were an 'rupdate', so I don't have to (cd /tmp; cvs co src/file/i/want.c) cp /tmp/src/file/i/want.c /where/i/want/it rm -rf /tmp/src all the time. # cd /tmp # cvs -d 'repo magic' export -rHEAD src/file/i/want.c Does `cvs export' do the trick for you? Actually, 'cvs export' does the opposite of what I want to do. But thank you for mentioning it, because it's a good way to explain what I'm trying to do, so people don't keep assuming that my problem is not knowing how to use CVS. 'cvs checkout': create a copy of the sources AND CVS's administrative directories 'cvs export': just create a copy of the sources What I want to do: just create the administrative directories I'm aware that making CVS magically discover what version I have is a bit much to ask for, so I'm willing to tell it what tag to use. Unfortunately, I don't think the facility I want exists, but I'm going to try to implement a workaround when I have a moment. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: State of the Union Report (backout request department)
Thus spake Wesley Morgan [EMAIL PROTECTED]: On Fri, 31 Jan 2003, Mike Barcroft wrote: The archives might not be telling the whole story. A lot of times these things get handled behind closed doors, whether private e-mail or developer-only lists. Thankfully though, most conflicts *do* get resolved. :) I have always LOVED watching the commits and backouts. I find it much more exciting to watch the actual development commit by commit, watch the brainiacs audit each other, and resolve to the best course. It seems much better than the way Linux traditionally did it (although they seem to have moved to bitkeeper) and much more like a professional development team. The problem is that once something is in the tree and someone asks for a backout, there is a stigma attached to it. It's as though the original committer would be admitting that he's wrong by backing it out, even if his commit is justified. So he gets defensive about it (and sometimes everyone else gets annoyed while their builds fail), and thus a DSW breaks out and people spend hours of their time being generally nasty and unproductive. People need to think of backouts as a form of bookkeeping and not as an admission of error. They should also try to minimize their occurrence, i.e. I shouldn't be able to read through the CVS logs and predict ``uh oh, there's gonna be hell about this...'' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Juli Mallett [EMAIL PROTECTED]: * De: Giorgos Keramidas [EMAIL PROTECTED] [ Data: 2003-01-31 ] [ Subjecte: Re: Seat-belt for source upgrades from stable to current ] On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote: Thus spake Mike Makonnen [EMAIL PROTECTED]: Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. That's a pretty good solution, and I use those occasionally. It would be a perfect solution if there were an 'rupdate', so I don't have to (cd /tmp; cvs co src/file/i/want.c) cp /tmp/src/file/i/want.c /where/i/want/it rm -rf /tmp/src all the time. # cd /tmp # cvs -d 'repo magic' export -rHEAD src/file/i/want.c Does `cvs export' do the trick for you? Further, export -d somedir might be useful in this situation to get the files where you want them, though sometimes -d does not DWIM, so I'm not sure :) That works when the revision has a symbolic tag associated with it, but export seems to be picky and won't do numeric revision numbers of particular files. I guess I could always go by date. And yes, -d is picky, too; you can't export into your working directory. Still, not bad... It doesn't address the entire problem I mentioned before, because I still want to do diffs between local revisions and the repository. This thread is just a subthread of the original thread in which I guess we're talking about how to do a 'cvs update' without a copy of the repository. (Sorry Giorgos, your idea actually works for updates, just not for the original question I was asking. I was confused. ENOSLEEP.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Thus spake Andrey A. Chernov [EMAIL PROTECTED]: Yes, first value correlation is there, but old formulae have even worse effect The random sequences do not vary much with the seed, as source file comments and whole discussion about old RNG bad effects shown. I.e. for different time+PID sequence, especially increased monotonically, like in common practice, you'l got the same random sequence with old formulae (which can't be called works fine because this fine work was the main reason for change). So, returning to old formulae is not an option. The real problem is not in formulae, but in srand() funclion. This simple patch can fix first value correlation, and I plan to commit it, if we all agree. I not find better value for NSHUFF right now, but think that something like 10 will be enough to fight corellation completely. Some generating picture tests needed. Throwing away the first 10 numbers is probably not good enough to eliminate randomness with respect to the initial seed. Knuth suggests throwing away the first 2000, but he is conservative.[1] But no amount of throwing away the initial sequence will help as long as the generator itself doesn't look very random. Specifically, rand() isn't very interesting in the lower-order bits, and it spectacularly fails nearly all of Marsaglia's randomness tests.[2] If rand() is a concern to someone, they should either find LCG parameters that produce better behavior, or research a replacement algorithm. [1] His PRNG is available from http://www-cs-faculty.stanford.edu/~knuth/programs/rng.c [2] http://stat.fsu.edu/~geo/diehard.html (you need ports/lang/f2c) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Thus spake Bakul Shah [EMAIL PROTECTED]: 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. If you need guaranteed reproducible random numbers that won't change from system to system or across libc versions, you need to roll your own PRNG. A simple linear congruential generator such as the original BSD algorithm might look random enough for your purposes. But I must admit that I was surprised when Andrey Chernov pointed out that rand() had been replaced between -CURRENT and -STABLE; I thought it was simply common knowledge that rand() was broken, and nobody was interested in fixing it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Thus spake Andrey A. Chernov [EMAIL PROTECTED]: On Sat, Feb 01, 2003 at 23:06:50 -0800, Kris Kennaway wrote: FreeBSD's rand() implementation has been broken for the past 23 months, since the following commit: i.e. the first value returned from rand() is correlated with the seed given to srand(). This is a big problem unless your seed is randomly chosen over its entire integer range. I noticed this because awk exhibits the same problem, and the script seeds the generator with a PID. The script works fine under 4.x since the rand() implementation does not have this feature. Yes, first value correlation is there, but old formulae have even worse effect The random sequences do not vary much with the seed, as source file comments and whole discussion about old RNG bad effects shown. I.e. for different time+PID sequence, especially increased monotonically, like in common practice, you'l got the same random sequence with old formulae (which can't be called works fine because this fine work was the main reason for change). So, returning to old formulae is not an option. The real problem is not in formulae, but in srand() funclion. This simple patch can fix first value correlation, and I plan to commit it, if we all agree. I not find better value for NSHUFF right now, but think that something like 10 will be enough to fight corellation completely. Some generating picture tests needed. The correlation is still present with your patch and NSHUFF set to 10. For instance, try seeding rand() with contiguous monotonically increasing integers, and observe the four lowest-order bits. Just for the heck of it, I ran Marsaglia's tests on the rand() implementation in -CURRENT. The arc4random() implementation passed with flying colors as expected, whereas rand() seems to have some slight defects, particularly in the lowest and highest order bits. When I looked at rand()'s behavior with respect to different seeds, it failed miserably, both with and without your patch. The results are available at http://www.csua.berkeley.edu/~das/marsaglia/ I'm not necessarily advocating changing the algorithm at all, given that it's well known that many rand() implementations are not very random. But I also don't buy the argument that ``rand() should never ever change.'' If someone wants to do the work to improve the algorithm, that's fine with me. David Wagner has collected some links on randomness that might be helpful: http://www.cs.berkeley.edu/~daw/rnd/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for correlation problem (was Re: rand() is broken)
Thus spake Thomas David Rivers [EMAIL PROTECTED]: I'm afraid I don't understand the fix... and how it seems to affect the historical behaviour of srand()/rand(). How does it address the understanding that if I use srand(28), I will get exactly the same sequence of numbers srand(28) produced yesterday, last week, last year? I have worked with programs that depend on exactly that behavior. That is, given the same input seed - I expect to see the same random sequence again. This requirement would seem to indicate that changing srand()/rand() isn't really possible... And, also, I believe, why random() was introduced... Please, oh please, don't change that behavior in srand()/rand(). There are two sides to this argument. One side says that rand() should always produce the same sequence for a given seed no matter what. This argument is bogus, because if you need exact reproducability across all platforms for all time, you should be using your own PRNG. The other side says that rand() should be a reasonably good RNG for most applications. It would be nice if things worked out that way, but there are enough broken rand() implementations out there that most people don't rely upon them. So I'd be inclined to call this argument bogus as well, except that I know someone who has been burned by a bad rand() while trying to test a randomized graph algorithm in C. My final thoughts are that having a better rand() implementation is a Good Thing, but it isn't that big a deal, and it certainly isn't worth all of this bickering. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Thus spake Andrey A. Chernov [EMAIL PROTECTED]:
On Sun, Feb 02, 2003 at 16:26:39 -0800, David Schultz wrote:
The correlation is still present with your patch and NSHUFF set to
10. For instance, try seeding rand() with contiguous monotonically
increasing integers, and observe the four lowest-order bits.
Since you already have running framework for that, could you please
test it with NSHUFF picked from 100-2000 range?
Rather than me showing you more semi-meaningful numbers from
Marsaglia's tests, why don't you look at the following sequence,
which I get by taking the lowest four bits of the 201st number in
the rand() sequence for seeds of (0, 1, 2, ...).
f c 9 6 2 f c 8 5 2 e b 8 4 1 e b 7 4 1 d a 7 3 0 d 9 6 3 f c 9
6 2 f c 8 5 2 e b 8 4 1 e b 7 4 1 d a 7 3 0 d 9 6 3 f c 9 6 2 f
c 8 5 2 e b 8 4 1 e a 7 4 1 d a 7 3 0 d 9 6 3 f c 9 6 2 f c 8 5
2 e b 8 4 1 e a 7 4 1 d a 7 3 0 d 9 6 3 f c 9 5 2 f c 8 5 2 e b
8 4 1 e a 7 4 1 d a 7 3 0 d 9 6 3 f c 9 5 2 f c 8 5 2 e b 8 4 1
e a 7 4 0 d a 7 3 0 d 9 6 3 f c 9 5 2 f c 8 5 2 e b 8 4 1 e a 7
4 0 d a 7 3 0 d 9 6 3 f c 9 5 2 f b 8 5 2 e b 8 4 1 e a 7 4 0 d
a 7 3 0 d 9 6 3 f c 9 5 2 f b 8 5 2 e b 8 4 1 e a 7 4 0 d a 7 3
0 d 9 6 3 f c 9 5 2 f b 8 5 2 e b 8 4 1 e a 7 4 0 d a 6 3 0 d 9
6 3 f c 9 5 2 f b 8 5 2 e b 8 4 1 e a 7 4 0 d a 6 3 0 d 9 6 3 f
Notice that 'f c 9' repeats in regular intervals and is always
followed by a 5 or 6. There is a similar pattern for 'e a 7'. I
think this pretty much demonstrates that the algorithm isn't good
enough to generate high-quality randomness with respect to
different seed values. I'm not suggesting that it absolutely must
be replaced, since most rand() implementations aren't very good in
the first place, but I'm pointing out that to do a good job of
fixing it once and for all is harder than you might think.
The program to generate this sequence follows. I ran this on a
several-month-old -CURRENT system with the new generator, but
without your latest patches.
#include stdio.h
#include stdlib.h
int main() {
int i, j;
for (i = 0; ; i++) {
srand(i);
for (j = 0; j 200; j++)
rand();
printf(%x , rand() 0x0f);
if (i % 32 == 31)
putchar('\n');
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Thus spake Eric Hodel [EMAIL PROTECTED]: David Schultz ([EMAIL PROTECTED]) wrote: Rather than me showing you more semi-meaningful numbers from Marsaglia's tests, why don't you look at the following sequence, which I get by taking the lowest four bits of the 201st number in the rand() sequence for seeds of (0, 1, 2, ...). f c 9 6 2 f c 8 5 2 e b 8 4 1 e b 7 4 1 d a 7 3 0 d 9 6 3 f c 9 6 2 f c 8 5 2 e b 8 4 1 e b 7 4 1 d a 7 3 0 d 9 6 3 f c 9 6 2 f c 8 5 2 e b 8 4 1 e a 7 4 1 d a 7 3 0 d 9 6 3 f c 9 6 2 f c 8 5 2 e b 8 4 1 e a 7 4 1 d a 7 3 0 d 9 6 3 f c 9 5 2 f c 8 5 2 e b 8 4 1 e a 7 4 1 d a 7 3 0 d 9 6 3 f c 9 5 2 f c 8 5 2 e b 8 4 1 e a 7 4 0 d a 7 3 0 d 9 6 3 f c 9 5 2 f c 8 5 2 e b 8 4 1 e a 7 4 0 d a 7 3 0 d 9 6 3 f c 9 5 2 f b 8 5 2 e b 8 4 1 e a 7 4 0 d a 7 3 0 d 9 6 3 f c 9 5 2 f b 8 5 2 e b 8 4 1 e a 7 4 0 d a 7 3 0 d 9 6 3 f c 9 5 2 f b 8 5 2 e b 8 4 1 e a 7 4 0 d a 6 3 0 d 9 6 3 f c 9 5 2 f b 8 5 2 e b 8 4 1 e a 7 4 0 d a 6 3 0 d 9 6 3 f Notice that 'f c 9' repeats in regular intervals and is always followed by a 5 or 6. There is a similar pattern for 'e a 7'. I think this pretty much demonstrates that the algorithm isn't good enough to generate high-quality randomness with respect to different seed values. I'm not suggesting that it absolutely must be replaced, since most rand() implementations aren't very good in the first place, but I'm pointing out that to do a good job of fixing it once and for all is harder than you might think. A littele modification shows just how similar these sequences are :) Yeah, I saw the periodicity when I asked less(1) to select particular subsequences. I guess it's a bit more impressive when you select the right modulus. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
Thus spake Andrey A. Chernov [EMAIL PROTECTED]: On Mon, Feb 03, 2003 at 21:40:20 -0800, David Schultz wrote: I don't try to make rand() good for high-quality pseudo-randomness, because it can be done by price of speed and, more important, big state size. Due to rand_r() restriction state size can be one word only, so we can choose rand() algorithm only from those which pass this restrictions. You can do better than the present generator with 32 bits of state. See the following page by Neal Wagner (not to be confused with David Wagner): http://www.cs.utsa.edu/~wagner/laws/rng.html The section on LCGs suggests that the multiplier FreeBSD uses (7^5) is not particularly good, and points out some better values suggested by Knuth. I can't find the original discussion in TAOCP vol. 2, but I take N. Wagner's word that the numbers have been blessed by the holy hand of Knuth. I'm sure you can find more information if you search the literature. I apologize, but I don't have time to help you right now, and rand() isn't really a concern to me. Returning to current algorithm, I am interested in good NSHUFF value in the range 100-2000. Do you have any findings there? Well, if 0 doesn't work, and 10 doesn't work, and 100 doesn't work, then I'm not too hopeful about 2000. I appeal to Asimov's zero, one, infinity law. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
Thus spake Ray Kohler [EMAIL PROTECTED]: Has anyone tried building world/kernel with high optimizations (-O2, -O3) recently? What breaks? (Booby prize to whoever says common sense ;) I last tried it quite a few months ago and the resolver died on me, don't know what else. I'm not really thinking of running like that, but I am curious about others' experiences. First, let me answer the question that you really meant to ask but forgot to, namely, ``How much of a performance difference does -O3 make over -O for the kernel/world?'' The answer is ``very little, for most purposes.'' So if you do use higher optimization levels, at least do a little benchmarking to make sure it was worth it. To answer your second question, higher optimization levels usually work, but there *will* be new bugs. I know of several libc problems due to -fstrict-aliasing, and I'm told that the inline assembly for TCP checksumming can still break. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
Thus spake Terry Lambert [EMAIL PROTECTED]: David Schultz wrote: Thus spake Ray Kohler [EMAIL PROTECTED]: Has anyone tried building world/kernel with high optimizations (-O2, -O3) recently? What breaks? (Booby prize to whoever says common sense ;) I last tried it quite a few months ago and the resolver died on me, don't know what else. I'm not really thinking of running like that, but I am curious about others' experiences. First, let me answer the question that you really meant to ask but forgot to, namely, ``How much of a performance difference does -O3 make over -O for the kernel/world?'' The answer is ``very little, for most purposes.'' So if you do use higher optimization levels, at least do a little benchmarking to make sure it was worth it. Actually, failure to use optimization suppresses some compilation warnings, particularly those which normally print from using some variables without initializing them. I think you're thinking of dataflow analysis, which I believe gcc does with -O and higher optimization levels. So unless you're using -O0, I would expect that you'd get all the warnings you want. There are a number of places, particularly on non-i386 platforms, where optimization actually doesn't work. I think that's why it was turned off for the libc compilation, and why the bug crept in. It's probably useful to compile world with optimization occasionally, to make compilation-time detectable bugs like that to show up, but, as you point out, it'd probably be a *bad* idea to actually use the resulting code, at least until after the next GCC import, which will supposedly fix the Alpha optimizer. Yes, the possibility of being bitten by compiler bugs is certainly higher with higher optimization levels. Alpha with -O2 seems to have been broken for years, and I have seen strange things happen on IA64 as well. But the i386 code generators have received much wider testing and debugging, so there is somewhat less danger there. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
Thus spake Terry Lambert [EMAIL PROTECTED]:
David Schultz wrote:
Thus spake Terry Lambert [EMAIL PROTECTED]:
Actually, failure to use optimization suppresses some compilation
warnings, particularly those which normally print from using some
variables without initializing them.
I think you're thinking of dataflow analysis, which I believe gcc
does with -O and higher optimization levels. So unless you're
using -O0, I would expect that you'd get all the warnings you
want.
See the thread Re: tmpfile breakage on setuid executables.
Kris accidently introduced a bug that had to do with whether or
not a variable was used before it was initialized. The compiler
didn't complain when he checked it before committing it because
optimization was off by default; it should have complained, e.g.:
x.c:9:warning: `foo' might be used uninitialized in this function
Thanks, I saw that. I'm just pointing out that all you need is -O
to get that warning:
das@bloody-mary:~ cat foo.c
int main() {
int foo;
return foo;
}
das@bloody-mary:~ gcc -o foo foo.c -Wall -O
foo.c: In function `main':
foo.c:2: warning: `foo' might be used uninitialized in this function
rant
This is one of those things that gcc3 does pretty well, but Sun's
javac does very badly. First of all, in Java, the above warning
is considered an error (except *maybe* in JDK 1.4, which is broken
and slow on IA64 so I can't use it). Second, the dataflow
analysis in javac is braindead, so the compiler is almost always
wrong. When I get the same warning from gcc, it's usually right
unless interprocedural analysis would be required.
/rant
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
Thus spake Adrian Chadd [EMAIL PROTECTED]: On Sat, Feb 08, 2003, David Schultz wrote: Yes, the possibility of being bitten by compiler bugs is certainly higher with higher optimization levels. Alpha with -O2 seems to have been broken for years, and I have seen strange things happen on IA64 as well. But the i386 code generators have received much wider testing and debugging, so there is somewhat less danger there. Yet squid under i386 freebsd is .. well, finds -O bugs in gcc. We gave up trying -O under FreeBSD a long time ago. :-) The last time someone told me, ``gcc -O is broken'', it turned out that they were doing some stack fiddling, and gcc's optimizations broke their faulty assumptions. On the other hand, I'm sure gcc -O does have bugs. Do you have an example snippet that gets miscompiled? (note: I've seen better performance gains by telling gcc exactly what CPU you have over -O65536 ..) Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
Thus spake Marcin Dalecki [EMAIL PROTECTED]: David Schultz wrote: Strangely, gcc in FreeBSD 5.0 actually generates *slower* code when compiling for more recent architectures than when compiling for a 386. I don't know whether that is a bug in gcc or whether gcc is using some fancy feature like SSE that the kernel handles poorly on context switches. I think there was some discussion on the lists about it earlier. The reason is that the optimization done by GCC are ill balanced. All the scheduling of instractions and what a not - which would be fine on a micro scope level is causing so much higher pressure on the CPUs caches that the code is actually loosing. Interesting. So they redid the code generation for gcc 3 and their new tricks backfired. But at least they fixed the completely braindead things gcc 2.9x was doing with alignment, floating point, and combinations thereof, and they got the compiler to do more reasonable things on ia64. Any idea when they will have fixed the i386 anti-optimizations? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
Thus spake Poul-Henning Kamp [EMAIL PROTECTED]: Somebody: please fix so this doesn't suck. Does msdosfs even have an active maintainer? There seem to be about half a dozen PRs open against it, one of which is a semi-obvious 4-line patch I submitted last April. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
