kmem_map too small
Dear colleagues, do you have any suggestions about how I should trace what condition generates kernel panic with reason "kmem_map too small"? Operating system is FreeBSD 6.2-p8, no unusual software runs on this machine -- it runs Asterisk with dummy Zapata driver, FreeRADIUS v1.1.7, MySQL v5.0 with single database for FreeRADIUS, Apache v1.3 for DialUp Admin. Sure, sshd, ntpd, syslogd. :) When this machine has run FreeBSD 5.4, no such problems were exist -- uptime was about 250 days. -- С уважением, Андрей Кольчугин. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kmem_map too small
В Пт, 16/11/2007 в 09:16 +0100, Kris Kennaway пишет: > Check the archives, this comes up a lot (you need to increase the amount > of memory allocated to the kernel). Already did. The question actually is how much memory I should allocate for kernel (exactly, what numbers should be placed into /boot/loader.conf in vm.kmem_size and vm.kmem_size_max) and what amount of kernel memory depends on and how I could calculate kernel memory needs. Trivial answer "just try to experiment" is not definitely enough. :) First of all, this process can be _extremely_ lengthy: about two months ago I have tried to "brute force" guess vm.kmem* values to start using ZFS on my desktop at work: two weeks for testing is very large amount of time, and, as said by Dijkstra, "testing can only show us presence of bugs, and not their absence": "cvs -z 5 -g up -P -d" done in /usr/ports (very good test to crash your machine if you're using ZFS because of heavy usage of ZFS POSIX name resolution cache) stopped crashing my box, but I can't say that any other test will not crash it. Second, the machine in question operates unattended, and our technical support engineers are not qualified enough to tweak boot loader parameters, as such, I should constantly monitor this server what I don't wish to do. :) -- С уважением, Андрей Кольчугин. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Random data corruption with USB mass storage on 7.0-BETA2
Am Donnerstag, 15. November 2007 20:34:57 schrieb Dennis Melentyev: > You need to check is it FAT12 or FAT16 on a card. AFAIR fdisk can show > this info. It's a FAT16 when formatted by the phone software (I checked that initially), but I can format the stick as FAT32 (by using newfs_msdos on the device) and still have the phone accept it, but when copying to the FAT32-formatted device random data corruption still occurs, i.e. the same problem noted in my last mail: 1) format device as FAT32 with newfs_msdos, 2) mount, 3) copy files, 4) unmount, (and don't plug the USB out) 5) mount, 6) checking files shows the metadata as being the same as before the unmount, but the files being different. The file corruption that occurs is similar: random, but not completely, because the differing file content comes at (somewhat) fixed offsets in the files. As I did not unplug the phone from the USB port while doing the FAT32 check run, the phone software never got a chance to actually access the memory stick while doing the above (Symbian blocks all accesses to the stick when USB in file-transfer mode is active), so I should guess the corruption comes purely from the host system. > Had the same problem with SE 64Mb card in K750i. It turned out that SE > creates FAT12 on a 32+Mb disk, which is not supposed to be an option. The K750i is not comparable, as the W600i is UIQ-based (i.e. Symbian + extras), whereas the K750i is not. > PS. To just make it work - just re-format it and restore folders > structure. But please, create a filesystem dump first, to let > developers decide is it a fault of SE phone or MSDOSFS code. After you talked about filesystem dumps, you got me an idea: 1) format the memory stick with the phone software 2) make a dump with dd (dd if=/dev/da0 of=disk.img bs=4k) 3) set that up as a memory disk, 4) mount that: lo and behold, the directory structure on the memory disk was just as it is displayed in the file manager of the phone (i.e., MEMSTICK.IND and MEMSTICK_PRO.IND were there in the root of the mount-point) 5) copy my files over to the mount point, 6) unmount the memory disk, 7) mount the memory disk, check files against the source, lo and behold, the files were equal (i.e., not corrupted during copy), 8) unmount the memory disk, 9) remove the memory disk, 10) copy the disk image back to the phone (dd if=disk.img of=/dev/da0 bs=4k) When I now access the memory stick from the phone (by unplugging it from USB), the files aren't corrupt. To finally test my hypothesis that this is a bug in the msdosfs-code, I mounted the device directly after doing this (which had MEMSTICK.IND and MEMSTICK_PRO.IND disappear again under the mount-point), copied some more files over, unmounted, remounted, and the same corruption seen before occurred again with the newly copied files (i.e., the phone software complained about broken MP3s when unplugging the phone from USB later on). Testing the old files (which I put on the memory stick with the above procedure) under the mount-point against the source showed them as being not equal, but the phone did not complain about corrupted MP3s when trying to play them, so basically on the "real" medium the data was still intact. If anybody wants to test with a dump of the filesystem or just more info, mail me, and I'll set that up somewhere as a download. For now, I'll personally try and see what changed between 6.2-STABLE and 7.0-BETA2 in the msdosfs-code that breaks this. -- Heiko Wundram Product & Application Development - Office Germany - EXPO PARK HANNOVER Beenic Networks GmbH Mailänder Straße 2 30539 Hannover Fon+49 511 / 590 935 - 15 Fax+49 511 / 590 935 - 29 Mobil +49 172 / 437 3 734 Mail [EMAIL PROTECTED] Beenic Networks GmbH - Sitz der Gesellschaft: Hannover Geschäftsführer: Jorge Delgado Registernummer: HRB 61869 Registergericht: Amtsgericht Hannover ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[8]: 6.3-PRERELEASE: interrupt storm detected on "irq11:"; throttling interrupt source, (irq11 is em0)
Hello, Jack. You wrote 16 ?? 2007 ?., 0:11:32: > OK, then we really have no control in the experiment, it could be > bad hardware. Oh! I can plug it into my desktop and boot from LiveCD with FreeBSD 6.2 Release. I'll try it this night. -- // Black Lion AKA Lev Serebryakov <[EMAIL PROTECTED]> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [HEADS UP] "freebsd-update rollback" broken on minor version upgrades
Colin Percival wrote: > A quick heads-up to everyone here using my new FreeBSD Update "upgrade" > code: If you have performed a minor version upgrade (e.g., 6.2-RELEASE -> > 6.3-BETA1 or 7.0-BETA1.5 -> 7.0-BETA2) please do not attempt to roll it > back using "freebsd-update rollback". > > That code is currently broken and will make your system unbootable. I > should have this fixed within the next couple of days. I have updated the code on my website and in the FreeBSD CVS tree. Anyone who downloads freebsd-update-upgrade.tgz from daemonology.net after this point, or anyone using the code in 6.3-RC1 or 7.0-RC1, should be able to rollback minor version upgrades successfully. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.3 or FreeBSD 7.0
Thu, 15 Nov 2007 22:31:19 + (GMT) Robert Watson <[EMAIL PROTECTED]> wrote: > I feel that the 7.0 kernel will prove to be one of our most stable, > not to mention most performant, .0 releases to date. Unfortunately, that's not true. For example, parallel printing crashes my amd64 system since the beginning of May. I've posted PR (kern/116669) which is still open. Some other people have reported about similar problems. To my mind it's a stopper defect for 7.0 because parallel printing is one of the basic computer tasks. FreeBSD was one of the best print servers for years. But at present it cannot be used in such a role (at least on amd64). Regards, Serguey. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ath support for mini-pci 802.11n card?
Has anyone tried the present ath driver with the mini-pc card described as .. "Netegriti 802.11n 802.11g 802.11b 802.11a Turbo Mini PCI Wireless Card" and advertised at http://discountechnology.com/Netegriti-802-11n-802-11g-802-11b-802-11a-Turbo-Mini-PCI-Wireless-Card It appears to be based on the Atheros AR5416, AR5133 chipsets but I can't work out from the sources if this combo is supported :-( Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kmem_map too small
Andrew Kolchoogin wrote: В Пт, 16/11/2007 в 09:16 +0100, Kris Kennaway пишет: Check the archives, this comes up a lot (you need to increase the amount of memory allocated to the kernel). Already did. The question actually is how much memory I should allocate for kernel (exactly, what numbers should be placed into /boot/loader.conf in vm.kmem_size and vm.kmem_size_max) and what amount of kernel memory depends on and how I could calculate kernel memory needs. Trivial answer "just try to experiment" is not definitely enough. :) First of all, this process can be _extremely_ lengthy: about two months ago I have tried to "brute force" guess vm.kmem* values to start using ZFS on my desktop at work: two weeks for testing is very large amount of time, and, as said by Dijkstra, "testing can only show us presence of bugs, and not their absence": "cvs -z 5 -g up -P -d" done in /usr/ports (very good test to crash your machine if you're using ZFS because of heavy usage of ZFS POSIX name resolution cache) stopped crashing my box, but I can't say that any other test will not crash it. Second, the machine in question operates unattended, and our technical support engineers are not qualified enough to tweak boot loader parameters, as such, I should constantly monitor this server what I don't wish to do. :) There is no general answer to that question since the amount of memory your system needs to use entirely depends on what you are doing with it. Increase the size by some percentage, e.g. 10% or 20%, and see if that is sufficient. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA2 Panic after ifconfig
On Nov 16, 2007 11:51 AM, Robert Watson <[EMAIL PROTECTED]> wrote: > > On Mon, 12 Nov 2007, Alexandre Biancalana wrote: > > > Before read your message I updated the system again (csup, buildworld, > > buildkernel, installkernel, installworld) and now I can reproduce the panic > > anymore. > > Sorry, just to clarify: you now cannot reproduce the panic, or you can still > reproduce the panic? Ops! My fault I *cannot* reproduce the panic. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA2 Panic after ifconfig
On Mon, 12 Nov 2007, Alexandre Biancalana wrote: Before read your message I updated the system again (csup, buildworld, buildkernel, installkernel, installworld) and now I can reproduce the panic anymore. Sorry, just to clarify: you now cannot reproduce the panic, or you can still reproduce the panic? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re[6]: 6.3-PRERELEASE: interrupt storm detected on "irq11:"; throttling interrupt source, (irq11 is em0)
On Nov 15, 2007 1:11 PM, Jack Vogel <[EMAIL PROTECTED]> wrote: > On Nov 15, 2007 12:54 PM, Lev Serebryakov <[EMAIL PROTECTED]> wrote: > > Hello, Jack. > > You wrote 15 ?? 2007 ?., 23:52:36: > > > > > Have you tried this NIC on anything previously, an older release? > > No... And I don't have spare computer for such test :( > > OK, then we really have no control in the experiment, it could be > bad hardware. > > Anyway, lets see if I can reproduce anything in our lab, hopefully > will know before the end of the day. Just so there is a record of the closure, we could not reproduce this and Lev sent me private email that this was a motherboard failure, so case closed :) Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7 on Soekris net4801?
On Thu, Nov 08, 2007 at 12:17:59PM +0100, Søren Schmidt wrote: > I'd figure that the problem is that the geode chip doesn't support 128 > sector writes just up to 126, that is not honered from the dump rutine > IIRC. Not only the dump routine fails, so does savecore(8): Physical memory: 251 MB Dumping 74 MB:ata0: FAILURE - oversized DMA transfer attempt 65536 > 64512 ad0: setting up DMA failed ... Checking for core dump on /dev/ad0s1b... ata0: FAILURE - non aligned DMA transfer attempted ad0: setting up DMA failed savecore: error reading last dump header at offset 536870400 in /dev/ad0s1b: Input/output error savecore: no dumps found Nov 16 19:13:07 tirith savecore: error reading last dump header at offset 536870400 in /dev/ad0s1b: Input/output error Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> pgpkIOIOY17Yg.pgp Description: PGP signature
Re: Float problen running i386 inary on amd64
On Sat, Nov 17, 2007 at 04:53:22AM +1100, Bruce Evans wrote:
>Behaviour like this should be expected on i386 but not on amd64. It
>gives the well-known property of the sin() function, that sin(x) != sin(x)
>for almost all x (!). It happens because expressions _may_ be evaluated
>in extra precision (this is perfectly standard), so identical expressions
>may sometimes be evaluated in different precisions even, or especially,
>if they are on the same line.
Thank you for your detailed analysis. Hwever, I believe you missed
the critical point (I may have removed too much reference to the
actual problem that Pete French saw): I can take a program that was
statically compiled on FreeBSD/i386, run it in legacy (i386) mode on
FreeBSD-6.3/amd64 and get different results.
Another (admittedly contrived) example:
jashank% uname -a
FreeBSD jashank.vk2pj.dyndns.org 6.1-STABLE FreeBSD 6.1-STABLE #15: Wed Aug 2
18:35:57 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/jashank i386
jashank% cat y.c
#include
double one = 1.0;
double three = 3.0;
double third = 1.0/3.0;
int main(int argc, char **argv)
{
if (one/three == third)
puts("Equal");
else
puts("NOT Equal");
return (0);
}
jashank% cc -O2 -fno-strict-aliasing -pipe -march=athlon y.c -static -o y
jashank% ./y
Equal
jashank% /sbin/sha256 y
SHA256 (y) = d44fe8c4c4b4beab6125ba603f2a34fa4d0280ff04d697e22594debf9efc9a1a
jashank%
turion% uname -a
FreeBSD turion.vk2pj.dyndns.org 6.2-STABLE FreeBSD 6.2-STABLE #30: Tue Jul 31
20:29:49 EST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/turion amd64
turion% scp -p jashank:y .
y 100% 146KB 145.9KB/s 00:00
turion% /sbin/sha256 y
SHA256 (y) = d44fe8c4c4b4beab6125ba603f2a34fa4d0280ff04d697e22594debf9efc9a1a
turion% ./y
NOT Equal
turion%
This is identical code being executed in supposedly equivalent
environments giving different results.
I believe the fix is to initialise the FPU using __INITIAL_NPXCW__ in
ia32_setregs(), though I'm not sure how difficult this is in reality.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgps0pNqgm4ZO.pgp
Description: PGP signature
Re: freebsd-update 6.2-R -> 6.3-B1 rollback failed
Jan Henrik Sylvester wrote: > Colin Percival wrote: >> I believe that your system is now 6.3-BETA1 with a few shared libraries >> from 6.2-RELEASE mixed in. If you can get a copy of /lib/*.so.* and >> /usr/lib/*.so.* from a 6.3-BETA1 system and install those into place >> (in fact, probably all you need is /lib/libc.so.6) your system should >> be ok. Let me know if you need any help with this. > > I guess I can download a 6.3-BETA1 cd and copy the files over from > there. If you have a better way, please, let me know. That's probably the safest approach. Theoretically you could get all of the files from FreeBSD Update's database in /var/db/freebsd-update/files, but actually finding the right ones and installing them is likely to be difficult and error-prone. >> Getting the system back to 6.2-RELEASE might be more difficult, now that >> the FreeBSD Update code thinks that it has rolled back its updates, but >> I might be able to find a way to do that for you -- is it a disaster if >> this system ends up stuck at 6.3-BETA1? > > Not to be able to go back to 6.2-RELEASE is ok. If updating to 6.3-BETA2 > (and eventually perhaps 7.0) is not possible because of the mixed > system, it will limit my testing and I will have to reinstall at some > point, which would not be a disaster, either. Upgrading to future releases should be fine. Once you get the libraries from 6.3-BETA1 installed again the system should be in exactly the same state as if you installed 6.3-BETA1 from the cd. > Is there any cleanup to do besides replacing the libs (such as removing > temporary freebsd-update directories)? You can save some disk space if you want by nuking everything in /var/db/freebsd-update/, but keeping those files will make upgrading to future releases with FreeBSD Update faster. > Since your blog seems not to tell and there is no other documentation: > Is freebsd-update -r supposed to work if not all files are from > GENERIC/SMP? Does it skip files or overwrite them with GENERIC versions? > (For security updates, the former might be desirable, but for updates > between releases, only the latter would make sense to me.) FreeBSD Update does its best to handle recompiled and/or customized kernels, according to the following rules: 1. If /boot/GENERIC or /boot/SMP exist, assume that they contain a GENERIC or SMP kernel respectively (and update it accordingly). 2. If the running kernel identifies itself as "GENERIC" or "SMP" (or as "SMP-GENERIC", which FreeBSD Update considers to be a synonym for "SMP"), assume it was built from the standard GENERIC or SMP kernel configuration. 3. If the running kernel identifies itself as something else, don't touch it. When upgrading, a couple more rules are applied: 1. If a custom kernel configuration is running, a warning message is printed telling the user to update the kernel manually before installing upgrades. 2. If the kernel configuration is one which was distributed in the current release but does not exist in the new release (e.g., FreeBSD 6.2 has "GENERIC" and "SMP" kernel configurations, but 7.0 only has a "GENERIC" configuration), upgrade it to a "GENERIC" kernel. In short, as long as you don't build a custom kernel but call it "GENERIC" or "SMP", FreeBSD Update should automatically DTRT. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Random data corruption with USB mass storage on 7.0-BETA2
Hello Heiko, Yes, you really have different issue. From now on, I have no more ideas. Hope you'll find the root of the problem. 2007/11/16, Heiko Wundram (Beenic) <[EMAIL PROTECTED]>: > Am Donnerstag, 15. November 2007 20:34:57 schrieb Dennis Melentyev: > > You need to check is it FAT12 or FAT16 on a card. AFAIR fdisk can show > > this info. > > It's a FAT16 when formatted by the phone software (I checked that initially), > but I can format the stick as FAT32 (by using newfs_msdos on the device) and > still have the phone accept it, but when copying to the FAT32-formatted > device random data corruption still occurs, i.e. the same problem noted in my > last mail: > > 1) format device as FAT32 with newfs_msdos, > 2) mount, > 3) copy files, > 4) unmount, (and don't plug the USB out) > 5) mount, > 6) checking files shows the metadata as being the same as before the unmount, > but the files being different. > > The file corruption that occurs is similar: random, but not completely, > because the differing file content comes at (somewhat) fixed offsets in the > files. > > As I did not unplug the phone from the USB port while doing the FAT32 check > run, the phone software never got a chance to actually access the memory > stick while doing the above (Symbian blocks all accesses to the stick when > USB in file-transfer mode is active), so I should guess the corruption comes > purely from the host system. > > > Had the same problem with SE 64Mb card in K750i. It turned out that SE > > creates FAT12 on a 32+Mb disk, which is not supposed to be an option. > > The K750i is not comparable, as the W600i is UIQ-based (i.e. Symbian + > extras), whereas the K750i is not. > > > PS. To just make it work - just re-format it and restore folders > > structure. But please, create a filesystem dump first, to let > > developers decide is it a fault of SE phone or MSDOSFS code. > > After you talked about filesystem dumps, you got me an idea: > > 1) format the memory stick with the phone software > 2) make a dump with dd (dd if=/dev/da0 of=disk.img bs=4k) > 3) set that up as a memory disk, > 4) mount that: lo and behold, the directory structure on the memory disk was > just as it is displayed in the file manager of the phone (i.e., MEMSTICK.IND > and MEMSTICK_PRO.IND were there in the root of the mount-point) > 5) copy my files over to the mount point, > 6) unmount the memory disk, > 7) mount the memory disk, check files against the source, lo and behold, the > files were equal (i.e., not corrupted during copy), > 8) unmount the memory disk, > 9) remove the memory disk, > 10) copy the disk image back to the phone (dd if=disk.img of=/dev/da0 bs=4k) > > When I now access the memory stick from the phone (by unplugging it from USB), > the files aren't corrupt. > > To finally test my hypothesis that this is a bug in the msdosfs-code, I > mounted the device directly after doing this (which had MEMSTICK.IND and > MEMSTICK_PRO.IND disappear again under the mount-point), copied some more > files over, unmounted, remounted, and the same corruption seen before > occurred again with the newly copied files (i.e., the phone software > complained about broken MP3s when unplugging the phone from USB later on). > Testing the old files (which I put on the memory stick with the above > procedure) under the mount-point against the source showed them as being not > equal, but the phone did not complain about corrupted MP3s when trying to > play them, so basically on the "real" medium the data was still intact. > > If anybody wants to test with a dump of the filesystem or just more info, mail > me, and I'll set that up somewhere as a download. > > For now, I'll personally try and see what changed between 6.2-STABLE and > 7.0-BETA2 in the msdosfs-code that breaks this. > > -- > Heiko Wundram > Product & Application Development > - > Office Germany - EXPO PARK HANNOVER > > Beenic Networks GmbH > Mailänder Straße 2 > 30539 Hannover > > Fon+49 511 / 590 935 - 15 > Fax+49 511 / 590 935 - 29 > Mobil +49 172 / 437 3 734 > Mail [EMAIL PROTECTED] > > > Beenic Networks GmbH > - > Sitz der Gesellschaft: Hannover > Geschäftsführer: Jorge Delgado > Registernummer: HRB 61869 > Registergericht: Amtsgericht Hannover > -- Dennis Melentyev ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ath support for mini-pci 802.11n card?
Michael Butler wrote: Has anyone tried the present ath driver with the mini-pc card described as .. "Netegriti 802.11n 802.11g 802.11b 802.11a Turbo Mini PCI Wireless Card" and advertised at http://discountechnology.com/Netegriti-802-11n-802-11g-802-11b-802-11a-Turbo-Mini-PCI-Wireless-Card It appears to be based on the Atheros AR5416, AR5133 chipsets but I can't work out from the sources if this combo is supported :- All 5416/5418-based cards will work in legacy mode w/ the hal found at http://www.freebsd.org/~sam. But since you can't (yet) use 11n there's not much reason to want an 11n card instead of a legacy card--especially given the cost. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Float problen running i386 inary on amd64
On Sat, 17 Nov 2007, Peter Jeremy wrote:
On Sat, Nov 17, 2007 at 04:53:22AM +1100, Bruce Evans wrote:
Behaviour like this should be expected on i386 but not on amd64. It
gives the well-known property of the sin() function, that sin(x) != sin(x)
for almost all x (!). It happens because expressions _may_ be evaluated
in extra precision (this is perfectly standard), so identical expressions
may sometimes be evaluated in different precisions even, or especially,
if they are on the same line.
Thank you for your detailed analysis. Hwever, I believe you missed
the critical point (I may have removed too much reference to the
actual problem that Pete French saw): I can take a program that was
statically compiled on FreeBSD/i386, run it in legacy (i386) mode on
FreeBSD-6.3/amd64 and get different results.
Another (admittedly contrived) example:
...
Ah, that explains it. This was also a longstanding bug in the Linux
emulator. linux_setregs() wasn't fixed to use the Linux npx control
word until relatively recently (2005). Linux libraries used to set
the control word in the C library (crt), which I think is the right
place to initialize it since the correct initialization may depend on
the language, so the bug wasn't so obvious at first.
This is identical code being executed in supposedly equivalent
environments giving different results.
I believe the fix is to initialise the FPU using __INITIAL_NPXCW__ in
ia32_setregs(), though I'm not sure how difficult this is in reality.
Yes, that is the right fix. It is moderately difficult to do correctly.
linux_setregs() now just uses fldcw(&control) where control =
__LINUX_NPXCW__. This depends on bugs to work, since direct accesses
to the FPU in the kernel are not supported. They cause a DNA trap
which should be fatal. amd64 is supposed to print a message about
this error, but it apparently doesn't else log files would be fuller.
i386 doesn't even print a message. npxdna() and fpudna() check related
invariants but not this one.
Correct code would do something like {fpu,npx}xinit(control) to
initialize the control word. setregs() in RELENG_[1-4] does exactly
that -- npxinit() hides the complications. Now {fpu,npx}init() is
only called once or twice at boot time for each CPU, and the complications
are a little larger since most initialization is delayed until the DNA
trap ({fpu,npx}init() now mainly sets up a copy of the initial FPU
state in memory for the trap handler to load later, and it cannot set
up per-thread state since the copy in memory is a global default).
The complications for delayed initialization are mainly to optimize
switching of the FPU state for signal handling, but are also used for
exec. Another complication here is that signal handlers should be
given the default control word. This is much more broken than for
setregs:
- there are sysent hooks for sendsig and sigreturn, but none for setting
registers in sendsig.
- all FreeBSD sendsig's end up using the gobal default initial FPU state
(if they support switching the FPU state at all).
- all Linux sendsig's are missing support for switching the FPU state.
- suppose that the initial FPU (or even CPU) state is language-dependent
and this is implemented mainly in the language runtime startup.
sendsig's would have a hard time determining the languages' defaults
so as to set them. The languages would need to set the defaults in
signal trampolines.
Bruce
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hook up idmapd to build in 6-stable?
I am beginning to dabble with NFSv4 client functionality. I noticed idmapd is not built in -stable but it has been in -current since src/sbin/Makefile v. 1.163 (13 months ago). Should it be hooked up to the build? Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hook up idmapd to build in 6-stable?
It was initially brought in by Alfred but I don't think anyone has done much work on NFSv4 on FreeBSD. It would be nice to have. -Kip On Nov 16, 2007 5:31 PM, Adam McDougall <[EMAIL PROTECTED]> wrote: > I am beginning to dabble with NFSv4 client functionality. I noticed > idmapd is not built in -stable but it has been in -current since > src/sbin/Makefile > v. 1.163 (13 months ago). Should it be hooked up to the build? Thanks > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
