Re: Missing system call in linux emulation ( patch )
Send a PR. On Thu, 14 Aug 2003, Steven Hartland wrote: I've created a patch for the linux emulation which adds a dummy for the exit_group syscall along with defining all functions up to 252 this fixes a crash in the BattleField 1942 server. How do I go about getting this into the various FreeBSD streams so others can benifit. Steve / K ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
What I find fascinating is that Maxtor's site never actually tells you the true throughput of that disk anywhere. http://www.maxtor.com/en/products/ata/desktop/diamondmax_plus_9/ Almost none of the hard disk manufacturers do. In fact I've never seen true throughput numbers from ANY manufacturer. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Maybe not, but they do give a transferspeed from medium range and that is what can be expected. Hmm, I guess not everyone does that. We have some seagates here at work we were wondering about because they seemed too slow, and we couldn't find anything aside from what we already knew... the tranfer speed of the SCSI interface, which is basically from drive cache to controller. That is unless the manufacturers hide the info somewhere so you really have to dig, which wouldnt' surprise me. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
http://www.maxtor.com/en/products/scsi/atlas_10k_family/atlas_10k_iv/index.htm maximum sustained data transfer rate up to 72MB/sec. http://www.seagate.com/cda/products/discsales/enterprise/family/0,1086,530,00.html Lists not only sustained transfer rate, but tells you the center and edge platter speed range http://ssddom01.hgst.com/tech/techlib.nsf/techdocs/966AE18147C20C8587256BF100656F41/$file/HGSTUltrastar146Z10.PDF Also lists center/edge sustained speeds Guess I just didn't look hard enough or in the right place. I only spent a minute or 2 on it, but yeah ATA drives don't tell you that sort of thing, they say stuff like ATA133 for a max transfer rate of 133 MB/sec * then at the bottom the * says something like 133 MB/sec burst rate from drive to controller or something similar. But I did try fairly hard to find specs on our Seagate drives and couldn't find a hard number that told what the maximum read and write speeds were. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Guess I just didn't look hard enough or in the right place. I only spent a minute or 2 on it, but yeah ATA drives don't tell you that sort of thing, they say stuff like ATA133 for a max transfer rate of 133 MB/sec * then at the bottom the * says something like 133 MB/sec burst rate from drive to controller or something similar. But I did try fairly hard to find specs on our Seagate drives and couldn't find a hard number that told what the maximum read and write speeds were. Thats maybe true for some drives, but generally they state this info in their docs, for the Diamond 9+ it took me 10 secs to find the below transfer speeds, I did have the PDF handy though :) Disk to Read Once a 236Mb/sec 236Mb/sec236Mb/sec 236Mb/sec Revolutionmminimumminimum minimum minimum 433Mb/sec 433Mb/sec433Mb/sec 433Mb/sec maximummaximum maximum maximum Disk to Read 257Mb/sec 257Mb/sec257Mb/sec 257Mb/sec Instantaneously minimumminimum minimum minimum 472Mb/sec 472Mb/sec472Mb/sec 472Mb/sec maximummaximum maximum maximum OK you win :-P I just don't know where to look I guess. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent mplayer port spinnin
Kenneth Maybe try it with FreeBSD-STABLE, or even FreeBSD 4.8? I've found Kenneth that occasionally, ports will work on later versions of FreeBSD Kenneth when they won't work on earlier ones. It's the same on 4.8 . Not that the issue bothers me, but merely not to help spread false hopes ( and I believe it is mplayer's problem ). Alright, I'm not sure how to help then, I have no -STABLE machines, mplayer works fine on my -CURRENT machines though. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recent mplayer port spinnin
Dunno how much further I want to chase this, but I wanted to ask the world first: For FreeBSD 4.7-R, I just (as in two days ago) reinstalled all of my packages via ports (cvsupped nightly). Now, often, mplayer spins upon quitting. It does print Exiting... (End of file), then never actually quits, it spins, eating my CPU, and I jave to -KILL it. Maybe try it with FreeBSD-STABLE, or even FreeBSD 4.8? I've found that occasionally, ports will work on later versions of FreeBSD when they won't work on earlier ones. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
The principal problem with libh is too many chiefs and not enough indians. Poor Alex and Max have done a HUGE amount of work on the system but it's large enough in scope that 2 people cannot hope to do it all by themselves, particularly when there's no relief shift to take things over when they get tired occasionally. From an architectural perspective, there's nothing which would stop libh from fulfilling all the dreams I've seen laid out here (and a number people haven't even mentioned yet, like scriptable installs or alternate look-and-feels). The principle thing standing in the way of this and every other let's get rid of sysinstall effort, for that matter, is a lack of engineers. This one's a bit like government. Everyone has an opinion about how it should work or what it could be doing better, but very few people want to actually get involved in changing it. :-) What needs done right now? I havn't seen much on libh recently... where is the source at? How can I get a look at it, and a list of what needs done so I can help. Just today at work, a friend of mine asked me how to install FreeBSD. He had tried it and had no luck whatsoever, so I had to walk him through it step-by-step. This would go a long way towards making an install process that could, for example, give the user the option of a newbie install which would be all graphical and pretty with X and what-not, and a experienced install which would bascially be the same installer we have now, only written on top of libh. Anyway, I'm interested in helping, I have 2 or 3 nights a week where I could write some code after work. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Drawing graphics on terminal
Nevermind, I found it: http://rtp1.slowblink.com/~libh/ Thanks. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
The HEAD code freeze was extended by three days to allow for some final pending work to be committed and prepare 5.1 to be a good release. The code freeze will likely end sometime tomorrow, May 30. We ask that large scale changes still be deferred until after 5.1 is actually released so that any problems can be dealt with. The release engineering team will send out emails explicitely stating when HEAD has thawed and when large changes like new compilers and dynamic-linked worlds can go it. The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. I'm just wondering... but is there a reason why gcc is being replaced? Is there a page or a previous list mail that explains the reasons? URL? Thanks. - Remove GNU tar. - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. - Remove ext2 support (GPL encumbered). - Add perl 5.8 *and* python 2.2 to base. - Remove Sendmail and replace it with Postfix. If anyone has any reason why these should not be committed, I'll give a 5 hours grace time. Send replies to the list. Thank you. Thorsten and the rest or the release engineering team. Thanks Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
nvclock0.6 port
Hi, I'm working on porting nvclock (the nvidia video card overclocking util), and I've got it working now. However, I don't have it clean enough to submit a port yet, but I wanted people to test the binaries I have (for -STABLE, the gtk binary requires gtk2 and both binaries require libgnugetopt). I'm putting the binaries up at http://wam.umd.edu/~culverk/nvclockbins.tar.gz Thanks... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
more on winex
Hi, I just realized that the --dll flags when you run winex are un-necessary... I just happened to try them at the same time I tried linking the linux libGL libraries to the plain versionless libGL.so and libGLcore.so. So it isn't necessary to do the --dll stuff. I'll post the full how-to as soon as possible. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: WarCraft III on FreeBSD
2 things, first try using the latest version of winex. Second, try editing /usr/compat/linux/usr/bin/winex (it's a shell script) so that #!/bin/sh says #!/usr/compat/linux/bin/bash I found that doing that solves a few problems for me, although I never had the problem you're having. Ken On Thu, 28 Nov 2002, Martin Faxer wrote: On Wed, Nov 27, 2002 at 10:06:44PM -0500, Kenneth Culver wrote: What flags are you starting winex with? Also, you can't run the game as normal I'm assuming because FreeBSD doesn't have block devices. The game needs to be able to check the cdrom, in order to be able to run, and it expects to see block devices (since linux still has them). I own a copy of Warcraft 3 but it seems that in order to get it working (until we have block devices working) you have to use a nocd hack. I'm not passing any flags at all to WineX. The suspend problem seems to happen with all .exe files I've tried so far. Even the simple ones that in theory should work, like eg. notepad.exe. This is what it looks like: redpixel@lockdown:/dos/Program Files/Warcraft III % /compat/linux/usr/bin/winex war3.exe zsh: suspended (signal) /compat/linux/usr/bin/winex war3.exe redpixel@lockdown:/dos/Program Files/Warcraft III % fg [1] + continued /compat/linux/usr/bin/winex war3.exe wine: Unhandled exception, starting debugger... redpixel@lockdown:/dos/Program Files/Warcraft III % uname -a FreeBSD lockdown.spectrum.fearmuffs.net 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Wed Nov 27 23:08:11 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LOCKDOWN i386 Needless to say, that signal wasn't sent by me :). Using that, and moving the Movies directory to Movies.bak in the installed warcraft directory, I am able to start it with: winex --dll quartz=n -- war3.exe (-opengl) The -opengl is optional. Have you tried this? I have now, and it doesn't cause any difference. The WineX process still gets suspended shortly after start-up. :( BTW, I'm using WineX 2.2a. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Warcraft3 on FreeBSD
Alright, I've never tested this on -CURRENT though... I don't see why it wouldn't work there though... Ken On Wed, 27 Nov 2002, Michael Reifenberger wrote: On Wed, 27 Nov 2002, Kenneth Culver wrote: Date: Wed, 27 Nov 2002 00:57:31 -0500 (EST) From: Kenneth Culver [EMAIL PROTECTED] To: Michael Reifenberger [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Warcraft3 on FreeBSD OK, the PR is located at http://www.freebsd.org/cgi/query-pr.cgi?pr=45785 The patch should be there as well. Ok, got it. Will test under -current first. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: WarCraft III on FreeBSD
I took much joy in reading about your getting WarCraft III running on FreeBSD, since FreeBSD is my OS of choice and well... WarCraft III is my game of choice :) However, you might want to check out the -CURRENT source; the missing Linux syscalls seem to be implented, except for truncate64(). Well truncate64 didn't need to be implemented, I just did it because I was there... However, I just checked my -CURRENT sources and it seems you're right. mmap2 is already done, and it seems to do the same thing my version does. Your version of mmap2() is considerably longer (although much of it is made up of comments). I'm not sure if there are any functional differences. There aren't, I just did a direct copy from the mmap source and changed things where they needed to be changed. I use -STABLE on my main machine, so I didn't check -current to see if mmap2 was there or not. So far I haven't had any success in getting WineX to run on -CURRENT: The WineX process gets suspended shortly after startup, and when I run 'fg' it just breaks into the debugger. :( I guess this might be due to the recent bulk of KSE and other related changes. What flags are you starting winex with? Also, you can't run the game as normal I'm assuming because FreeBSD doesn't have block devices. The game needs to be able to check the cdrom, in order to be able to run, and it expects to see block devices (since linux still has them). I own a copy of Warcraft 3 but it seems that in order to get it working (until we have block devices working) you have to use a nocd hack. Using that, and moving the Movies directory to Movies.bak in the installed warcraft directory, I am able to start it with: winex --dll quartz=n -- war3.exe (-opengl) The -opengl is optional. Have you tried this? If you make any attempts at running WineX on -CURRENT, I'd very much like to hear about them! Again, thanks for doing this. Once WC III works under FreeBSD my Windows partition will be gone ;) Thanks Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Warcraft3 on FreeBSD
You don't have anything to commit :-) mmap2 already exists in -CURRENT, it's only missing in -STABLE. So I'd think you probably don't have to worry about it. Ken On Wed, 27 Nov 2002, Matthew Dillon wrote: Remember, we are in code-freeze on -current at the moment. I took a quick look at the patch set and it looks fine to me. I think the patch set can be committed (and MFCd) after the freeze is lifted. If someone else doesn't get to it first, just remind me after the freeze is lifted and I would be happy to do the work. -Matt Matthew Dillon [EMAIL PROTECTED] : :Alright, I've never tested this on -CURRENT though... I don't see why it :wouldn't work there though... : :Ken : :On Wed, 27 Nov 2002, Michael Reifenberger wrote: : : On Wed, 27 Nov 2002, Kenneth Culver wrote: : : Date: Wed, 27 Nov 2002 00:57:31 -0500 (EST) : From: Kenneth Culver [EMAIL PROTECTED] : To: Michael Reifenberger [EMAIL PROTECTED] : Cc: [EMAIL PROTECTED] : Subject: Re: Warcraft3 on FreeBSD : : OK, the PR is located at : : http://www.freebsd.org/cgi/query-pr.cgi?pr=45785 : : The patch should be there as well. : Ok, got it. : Will test under -current first. : : Bye! : : Michael Reifenberger : ^.*Plaut.*$, IT, R/3 Basis, GPS : : : To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
WC3 screenshots
Here are some screenshots of winex running warcraft3 on FreeBSD. http://www.wam.umd.edu/~culverk/scrnshot.jpg http://www.wam.umd.edu/~culverk/scrnshot2.jpg http://www.wam.umd.edu/~culverk/scrnshot3.jpg The how-to will be up probably in a few more days. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Warcraft3 on FreeBSD
Just in case anyone here cares, I have implemented the linux ftruncate64, truncate64, and mmap2 syscalls in the linuxulator on my computer, (mostly cut 'n pasted the mmap2 from regular mmap with a couple of changes) and with these changes it is possible to run the linux version of winex (the one you have to pay for) to run warcraft 3. IT works in both direct3d mode and in opengl mode using the following commandline: winex --dll dsound=n --dll quartz=n --dll d3d8=b War3.exe -- War3.exe Anyway, just thought someone might want to know. If anyone wants step-by-step instructions to getting this working I'll have those worked up in the next few days and posted somewhere along with the patches to the linux kernel module. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Warcraft3 on FreeBSD
I havn't submitted them to anyone b/c I wanted more people to test them. The patches work fine with everything I've tried though (using the linux_base-7.1 package). I've tested linux-mozilla, quake3, Unreal Tournament 2003, Return to castle Wolfenstein, and now winex. (winex won't work without the patches). So I take it you're interested in messing with the patches I have? Yes. I'm using suse8. I had the impression that glibc had fallbacks to the old (non64) functions when not present in kernel I could get it commited but Im not shure when. Current is under code freeze yet. Either we get re@ approval or have to wait until 5.0 is out. Well the kernel patches MIGHT not even be necessary, I'm not sure because I only tried a little bit without them. There could be a fallback. Almost nothing would run right without the mmap2, it would run and crash at one place or another. For all the syscalls, I noticed that they weren't implemented, and they were easy enough to implement (ftruncate64 and truncate64 were similar to truncate, and mmap2 was almost a complete cut 'n paste from the mmap that's already there, just used ctob(pgoff) for pos I believe), so I did it. My patches are to a -STABLE machine though, so there'd probably be a little work necessary in getting them on to -CURRENT unless the linuxulators have stayed the same between the two versions of FreeBSD. I had help from a few people from the lists with the mmap2, although I can't remember who helped. Anyway, I'll submit a PR once I clean up the patches a bit. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Warcraft3 on FreeBSD
On Wed, 27 Nov 2002, Michael Reifenberger wrote: On Tue, 26 Nov 2002, Kenneth Culver wrote: ... Anyway, I'll submit a PR once I clean up the patches a bit. Yes, please. Please post the number when ready. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS Does a mail come back to me with the pr number or something? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Warcraft3 on FreeBSD
OK, the PR is located at http://www.freebsd.org/cgi/query-pr.cgi?pr=45785 The patch should be there as well. Thanks Ken On Wed, 27 Nov 2002, Michael Reifenberger wrote: On Tue, 26 Nov 2002, Kenneth Culver wrote: ... Anyway, I'll submit a PR once I clean up the patches a bit. Yes, please. Please post the number when ready. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Wierd message followed mem prob
Hi, This is in addition to my last mail. Just to reiterate, I'm using FreeBSD 4.7-STABLE as of a few days ago, and I've never seen this problem before. The wierd message comes from /usr/src/sys/i386/i386/machdep.c: Too many holes in the physical address space, giving up It prints before even the copyright message on bootup. Second is (I think as a result of this message) My total memory is too small by over 100M (I have 512M): Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.7-STABLE #0: Mon Nov 25 04:25:46 EST 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/MYKERNEL Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(tm) XP 2000+ (1667.40-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! real memory = 402669568 (393232K bytes) avail memory = 386879488 (377812K bytes) Anyone know what's going on/how to fix it? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
mmap2 implementation for winex
Hi,
I recently installed linux winex (again) now that I have working
nVidia drivers. However I found that almost nothing worked and there was a
message about mmap2 not being implemented. I implemented it, but I'm not
sure if it's done right... because some things started working after I
implemented it, but a lot of software that is supposed to work with it
still doesn't. For those who don't know, winex is a version of wine that
supports running windows games that require direct3d to work.
Here is my mmap2 implementation, based on the current mmap:
int
linux_mmap2(struct proc *p, struct linux_mmap2_args *linux_args)
{
struct mmap_args /* {
caddr_t addr;
size_t len;
int prot;
int flags;
int fd;
long pad;
off_t pos;
} */ bsd_args;
bsd_args.flags = 0;
if (linux_args-flags LINUX_MAP_SHARED)
bsd_args.flags |= MAP_SHARED;
if (linux_args-flags LINUX_MAP_PRIVATE)
bsd_args.flags |= MAP_PRIVATE;
if (linux_args-flags LINUX_MAP_FIXED)
bsd_args.flags |= MAP_FIXED;
if (linux_args-flags LINUX_MAP_ANON)
bsd_args.flags |= MAP_ANON;
else
bsd_args.flags |= MAP_NOSYNC;
if (linux_args-flags LINUX_MAP_GROWSDOWN) {
bsd_args.flags |= MAP_STACK;
/* The linux MAP_GROWSDOWN option does not limit auto
* growth of the region. Linux mmap with this option
* takes as addr the inital BOS, and as len, the initial
* region size. It can then grow down from addr without
* limit. However, linux threads has an implicit internal
* limit to stack size of STACK_SIZE. Its just not
* enforced explicitly in linux. But, here we impose
* a limit of (STACK_SIZE - GUARD_SIZE) on the stack
* region, since we can do this with our mmap.
*
* Our mmap with MAP_STACK takes addr as the maximum
* downsize limit on BOS, and as len the max size of
* the region. It them maps the top SGROWSIZ bytes,
* and autgrows the region down, up to the limit
* in addr.
*
* If we don't use the MAP_STACK option, the effect
* of this code is to allocate a stack region of a
* fixed size of (STACK_SIZE - GUARD_SIZE).
*/
/* This gives us TOS */
bsd_args.addr = (caddr_t)(linux_args-addr +
linux_args-len);
if (bsd_args.addr p-p_vmspace-vm_maxsaddr) {
/* Some linux apps will attempt to mmap
* thread stacks near the top of their
* address space. If their TOS is greater
* than vm_maxsaddr, vm_map_growstack()
* will confuse the thread stack with the
* process stack and deliver a SEGV if they
* attempt to grow the thread stack past their
* current stacksize rlimit. To avoid this,
* adjust vm_maxsaddr upwards to reflect
* the current stacksize rlimit rather
* than the maximum possible stacksize.
* It would be better to adjust the
* mmap'ed region, but some apps do not check
* mmap's return value.
*/
p-p_vmspace-vm_maxsaddr = (char *)USRSTACK -
p-p_rlimit[RLIMIT_STACK].rlim_cur;
}
/* This gives us our maximum stack size */
if (linux_args-len STACK_SIZE - GUARD_SIZE)
bsd_args.len = linux_args-len;
else
bsd_args.len = STACK_SIZE - GUARD_SIZE;
/* This gives us a new BOS. If we're using VM_STACK, then
* mmap will just map the top SGROWSIZ bytes, and let
* the stack grow down to the limit at BOS. If we're
* not using VM_STACK we map the full stack, since we
* don't have a way to autogrow it.
*/
bsd_args.addr -= bsd_args.len;
} else {
bsd_args.addr = (caddr_t)linux_args-addr;
bsd_args.len = linux_args-len;
}
bsd_args.prot = linux_args-prot | PROT_READ; /* always required
*/
if (linux_args-flags LINUX_MAP_ANON)
bsd_args.fd = -1;
else
bsd_args.fd = linux_args-fd;
bsd_args.pos = ctob(linux_args-pgoff);
bsd_args.pad = 0;
return (mmap(p,
RE: panic with nvidia drivers (but not sure it's nvidia's fault)
Looks like it is indeed nvidia's fault. It called atomic_clear_short() with an invalid pointer in nv_alloc_pages(). You might be able to look at nv_alloc_pages() to try and figure out the bug. nv_alloc_pages never actually calls atomic_clear_short(), but it does call several functions that call vm_object functions in FreeBSD's kernel that eventually call atomic_clear_short(). For some reason those functions in between aren't in the backtrace though, and without that I can (and have) look through the code in the kernel to see how nv_alloc_pages can get to atomic_clear_short through vm calls, but I'm not sure that's too awefully helpful. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: panic with nvidia drivers (but not sure it's nvidia's fault)
several functions that call vm_object functions in FreeBSD's kernel that eventually call atomic_clear_short(). For some reason those functions in between aren't in the backtrace though, and without that I can (and have) look through the code in the kernel to see how nv_alloc_pages can get to atomic_clear_short through vm calls, but I'm not sure that's too awefully helpful. Actually, after tracing through again, it appears to be following this codepath: (in reverse order from a backtrace) nv_alloc_pages() nv_free_vm_object() vm_object_deallocate() vm_object_clear_flag() atomic_clear_short() so I think it's possible that something may be getting screwed up between nv_free_vm_object and atomic_clear_short(). I'm not really sure how to tell though. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: panic with nvidia drivers (but not sure it's nvidia's fault)
Are you sure that nv_free_vm_object() is free'ing a valid object? I'm not positive, but looking at the code this is what happens. first an object is allocated, then it goes and finds some nvidia specific data structure contained in that object (from what I can tell), then it calls rm_alloc_agp_pages (which is a function that I don't have access to. it is in the proprietary part of the driver I guess), then calls nv_free_vm_object(). I suppose that rm_alloc_agp_pages could very well be screwing up the vm object, in which case the bug really is nvidia's driver's fault. Thanks. I feel better now because this whole piece of code can be totally avoided by using FreeBSD's agpgart instead of nvidia's :-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: panic with nvidia drivers (but not sure it's nvidia's fault)
It'd be interesting to learn if the code path you suspect really is the one taken in the case of this failure. Is this problem easily reproducible on your machine? If so, how and with what hard/software combination? I think the stack is getting (somewhat) smashed so there's no real way to tell for sure if this is the code path that is taken, but it's the only one that goes from nv_alloc_pages to the atomic_clear_flags() (at least the only one I've found so far). The problem is EXTREMELY reproducable. Hardware: Abit KX333 mobo (via KT333 chipset) 256MB Crucial (micron) pc2100 DDR SDRAM. Athlon XP 2000+ Geforce 3 Ti 200 I'm using agp 4x. To reproduce the problem, all I have to do is run ut2003. It always dies just after the splash screen comes up (apparently after it changes resolution to 800x600 on my machine.) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: panic with nvidia drivers (but not sure it's nvidia's fault)
All code interacting with FreeBSD data structures resides in the open part of the kernel module; a pointer to the newly allocated object is passed to rm_alloc_agp_pages as an opaque pointer, it is required later when the NVIDIA AGP GART driver needs to obtain the physical addresses of the individual pages in the allocation. This happens with calls to nv_agp_translate_address. I don't see rm_alloc_agp_pages anywhere in the open part of the source code. I just looked again... I see the function prototype in nv.h, but that's it. screwdriver:~/dl_temp/NVIDIA_FreeBSD-1.0-3203: grep -R rm_alloc_agp_pages * Binary file obj/Module-nvkernel matches src/nvidia_subr.c:if (rm_alloc_agp_pages(nv, address, count, class, private, src/nvidia_subr.c:if (rm_alloc_agp_pages(nv, address, count, class, private, src/nv.h:RM_STATUS rm_alloc_agp_pages (nv_state_t *, VOID **, U032, U032, VOID **, U032 *); so from what I can tell, it IS in the proprietary part of the driver. It'd be interesting to learn if the code path you suspect really is the one taken in the case of this failure. Is this problem easily reproducible on your machine? If so, how and with what hard/software combination? Given the above, I'm inclined to think my original trace through the code is correct, although I didn't look to closely. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
panic with nvidia drivers (but not sure it's nvidia's fault)
I'm posting this here because of a panic I'm getting using the FreeBSD nvidia driver; however, I'm not convinced that this panic is the fault of the driver, and I wanted to post the backtrace here (from a serial console, can't see anything on the pc console during this crash since X is up) just in case it's FreeBSD's fault. atomic_clear_short(c1596400,d2ae5a40,1556,1556,d2ae5a40) at atomic_clear_short+0xb nv_alloc_pages(c1596400,d2ae5a40,1556,1,1) at nv_alloc_pages+0x37 __nvsym00150(c17a4000,d2ae5a40,1556,1,1) at __nvsym00150+0x4b __nvsym00142(c17a4000,c1d00021,d2ae5a40,d2ae5a44,d2ae59e4) at __nvsym00142+0x120 __nvsym00153(c1d00021,beef0003,beef0020,3e,2100) at __nvsym00153+0x84 __nvsym00606(c1596400,c1690a00,27,d2ae5e88,d2ae5d24) at __nvsym00606+0x35b rm_ioctl(c1596400,c1690a00,27,d2ae5e88,d2ae5d6c) at rm_ioctl+0x17 nvidia_handle_ioctl(c15ab500,c0284627,d2ae5e88,3,cc322520) at nvidia_handle_ioctl+0x53 nvidia_dev_ioctl(c15ab500,c0284627,d2ae5e88,3,cc322520) at nvidia_dev_ioctl+0x3a spec_ioctl(d2ae5dc4,d2ae5dac,c01b99b1,d2ae5dc4,d2ae5e54) at spec_ioctl+0x26 spec_vnoperate(d2ae5dc4,d2ae5e54,c017cb37,d2ae5dc4,c1867f40) at spec_vnoperate+0x15 ufs_vnoperatespec(d2ae5dc4,c1867f40,0,28,c025b000) at ufs_vnoperatespec+0x15 vn_ioctl(c1867f40,c0284627,d2ae5e88,cc322520,c0e34700) at vn_ioctl+0x10f ioctl(cc322520,d2ae5f80,d2ae5f34,c030bd70,cc322520) at ioctl+0x20a linux_ioctl_nvidia(cc322520,d2ae5f80,cc322520,3,c0314088) at linux_ioctl_nvidia+0xe linux_ioctl(cc322520,d2ae5f80,60,bfbfce90,80e9150) at linux_ioctl+0x54 syscall2(2f,2f,2f,80e9150,bfbfce90) at syscall2+0x16a Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc1d00025 fault code = supervisor read, page not present instruction pointer = 0x8:0xc020f52c stack pointer = 0x10:0xd2ae5664 frame pointer = 0x10:0xd2ae5668 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 172 (ut2003-bin) interrupt mask = none kernel: type 12 trap, code=0 Any ideas? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
You might want to give that a bit of thought. IBM, while producing OK scsi disks, has had a really terrible headache getting reliability into their IDE products. Additionally, IBM just sold their entire hard disk product line to some other company. I don't know if that had anything to do with their well-publicized IDE reliability problems or not, but I'd fight shy of any IBM IDE disks, in any app which requires any kind of stability. If you don't care about reliability, tho, there are some good deals I've seen on those disks, tho ... being dumped in mass cheaply. Again, this has nothing to do with their scsi disks, which are just fine. I'd probably steer clear of the western digital drives as well. Yes the 8MB cache that some of them have DOES make a difference, but from personal experience, the drives themselves don't last that long. So in short, what good is a fast hard-drive if it's just going to break faster too? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
I'd probably steer clear of the western digital drives as well. Yes the make that stear clear. 8MB cache that some of them have DOES make a difference, but from personal experience, the drives themselves don't last that long. So in short, what good is a fast hard-drive if it's just going to break faster too? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
I haven't had any trouble with the WDxxxBB drives - the WDxxxAA drives are pretty unreliable though. Hrmm, I havn't tried those, but just about every WD drive I've used has ended up with problems which were of course handled by the warranty, but even then, I still had to reinstall the os and pull a bunch of stuff from my backups which was a pain to do for each failure. Like I said, just my personal experience. I don't think the new 8MB cache drives have been out long enough to actually develop the problems I've seen on WD drives though. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
Yes, but my point is that the AA drives are bad, but the BB drives seem good. I have been using them for a while (~1 year) without trouble. I believe the JB drives are much more closely related to the BB drives (ie effectively identical but with a bigger cache). Personally I find that no HD manufacturer has a good reputation - they have all made trashy drives at one point. Give the general time it takes for problems to surface vs product lifetimes makes deciding what to buy a PITA :( I'll agree with that :-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [hardware] Tagged Command Queuing or Larger Cache ?
Ummm... why? steer is a word with multiple meanings. I can't find stear anywhere. well, lets just say that my brain is fried b/c of midterms. OK? :-P Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Porting libc_r from -current to -stable
| Just curious, but what does doing this port get you? Better threading performance and less bugs in Java, so I'm told. I was looking for a Java on BSD project, and this is what I was given. Oh, I didn't realize the userland threads implementations on -current and -stable differed that much. Good luck! Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: offtopic: low level format of IDE drive.
this is not a 'reformat' what I want to do is an old-fashionned refomat/verify where the controller writes new track headers etc. You want to follow terry's advice then. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Question about the compile a kernel for Sparc
or would I need extra tools for cross compiling I think I would cos you did for the powerpc port that I never got around to going all the way with. Most likely you'd need the cross-compiling tools. Ken any help appreciated. Bri, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: WakeOnLan on 3C905C-TX not working?
ctrl-alt-B gives me a utility to select things in the netbooting area. But no selection of WOL. Is this what you saw on your card? I'll have to check when I get home from work... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: WakeOnLan on 3C905C-TX not working?
On Wed, May 01, 2002 at 05:10:55PM -0400, Jason Andresen wrote: Wilko Bulte wrote: For lack of a better list: I'm trying to use the net/wakeonlan port to remotely switch on a machine that is equipped with a 3COM 3C905C-TX PCI 10/100 card. WOL is enabled in the BIOS, I tried this on an ASUS and on an ECS mainboard, I sent the wakeonlan packet from different machines, ethereal sees a packet which appears to follow the magic packet standard. The card's LEDs say lit, and flicker when the packet arrives. But the endresult: the machines simply ignore it. This is my first ever WOL attempt, and I'm stumped. Suggestions? 1. Is your bios configured to ignore the WoL signal? No, I explicitely enabled WOL in the BIOS. 2. Did you remember to attach that little cable from your card to the motherboard? Yep :) a. Is it plugged into the right spot (this is pretty hard to get wrong actually). Yes, that is wired correctly, there is a polarising notch (sp?) on the plastic of the connector. Do I need to configure the 3C905C somehow? The diag tools I tried don't allow me to afaics. I have the same card, and if I remember correctly, there is a config util that's built into the card, although I don't remember how to access it... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pushal ebp
I just looked at the NetBSD code like linux, they use a macro which individually pushes the registers onto the stack rather than using pushal (which I assume is the same as what intel calls PUSHAD in their x86 instruction set ref. manual). NetBSD stopped using pushal in 1994 in rev 1.85 of their arch/i386/i386/locore.s in a commit helpfully documented Don't use pusha and popa. Does anybody know why the other OSes push the registers individually, rather than using pushal? Could our using pushal be causing Kenneth's ebp to get lost, or is this just a red herring? Thanks, Drew according to the intel docs, pushad (or what I'm assuming is pushal in our case) pushes eax, ecx, edx, ebx then pushes some temporary value (the original esp I think) then pushes ebp, esi, and edi: this is from the documentation for pushad IF OperandSize = 32 (* PUSHAD instruction *) THEN Temp (ESP); Push(EAX); Push(ECX); Push(EDX); Push(EBX); Push(Temp); Push(EBP); Push(ESI); Push(EDI); so could this be the problem? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pushal ebp
On Thu, 25 Apr 2002, Andrew Gallatin wrote: Kenneth Culver writes: I just looked at the NetBSD code like linux, they use a macro which individually pushes the registers onto the stack rather than using pushal (which I assume is the same as what intel calls PUSHAD in their x86 instruction set ref. manual). NetBSD stopped using pushal in 1994 in rev 1.85 of their arch/i386/i386/locore.s in a commit helpfully documented Don't use pusha and popa. Does anybody know why the other OSes push the registers individually, rather than using pushal? Could our using pushal be causing Kenneth's ebp to get lost, or is this just a red herring? Thanks, Drew according to the intel docs, pushad (or what I'm assuming is pushal in our case) pushes eax, ecx, edx, ebx then pushes some temporary value (the original esp I think) then pushes ebp, esi, and edi: this is from the documentation for pushad IF OperandSize = 32 (* PUSHAD instruction *) THEN Temp (ESP); Push(EAX); Push(ECX); Push(EDX); Push(EBX); Push(Temp); Push(EBP); Push(ESI); Push(EDI); so could this be the problem? Ken I don't think so. The temp its pushing is the stack pointer. If you look at the layout of the trap frame, then you'll see tf_isp comes between tf_ebp tf_ebx. I assume tf_isp is the stack pointer, so that should be OK.. Drew hrmm, well then it looks like pushal should be doing the right thing... but I thought though that esp was the stack pointer... it's pushing the original stack pointer onto isp, and then pushing ebp... I don't see why this would screw anything up... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
I tried printing out everything in the trapframe in hex and nothing looke remotely right. Ken On 24 Apr 2002, Brandon S Allbery KF8NH wrote: On Wed, 2002-04-24 at 10:41, Andrew Gallatin wrote: Maybe the argument isn't where you expect it to be, but is there. Can you make a test program which calls mmap2 with its 6th arg as something unique like 0xdeadbeef? Then print out (in hex :) the trapframe from the linux prepsyscall routine see if you can find the deadbeef. My recollection is that beyond 5 arguments, a pointer to the remaining ones is passed. (But my recollection may be wrong and I don't wish to subject myself to the source cesspool at the moment) -- brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineeringKF8NH carnegie mellon university [better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
libc sets it before it enters the kernel. Then on kernel entry we save ebp in the trapframe. So in the case of linux emulation, the glibc that we're using in the linux-ulator isn't setting it properly? I'm using the linux_base-7 port for this, so as far as I can tell, it should work... assuming linux_base-7 is meant to run on a linux-2.4.x kernel (or kernel that's emulating that). I may have screwed up my linux libs somehow or another too... could this be causing the behavior I'm seeing? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
libc sets it before it enters the kernel. Then on kernel entry we save ebp in the trapframe. So in the case of linux emulation, the glibc that we're using in the linux-ulator isn't setting it properly? I'm using the linux_base-7 port for this, so as far as I can tell, it should work... assuming linux_base-7 is meant to run on a linux-2.4.x kernel (or kernel that's emulating that). I may have screwed up my linux libs somehow or another too... could this be causing the behavior I'm seeing? Ken OK, I removed the linux_base packages that I had on here, and made some changes to the linux-ulator (added the arg[5] = tf-tf_ebp, and then re-installed the linux_base-7.1 package, and now things are working... winex is working fine now. :-) I'll clean up my changes to the linux-ulator, and submit them as a pr. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
libc sets it before it enters the kernel. Then on kernel entry we save ebp in the trapframe. So in the case of linux emulation, the glibc that we're using in the linux-ulator isn't setting it properly? I'm using the linux_base-7 port for this, so as far as I can tell, it should work... assuming linux_base-7 is meant to run on a linux-2.4.x kernel (or kernel that's emulating that). I may have screwed up my linux libs somehow or another too... could this be causing the behavior I'm seeing? Ken OK, I removed the linux_base packages that I had on here, and made some changes to the linux-ulator (added the arg[5] = tf-tf_ebp, and then re-installed the linux_base-7.1 package, and now things are working... winex is working fine now. :-) I'll clean up my changes to the linux-ulator, and submit them as a pr. I'm actually still not seeing a match between what's in truss, and what's in my printed-out args, but it seems to be working anyway... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
I'm actually still not seeing a match between what's in truss, and what's in my printed-out args, but it seems to be working anyway... Argh, it's not working again... It was working on an install of ms office, but it won't work on some old windows game.. (winex) and it's still not setting the last arg (or register properly): truss output: linux_mmap2(0x6543,0x10,0x3,0x11,0x9,0x6) = 1698889728 (0x6543) notice that the last arg is 0x6, that's the page offset... what the kernel prints for the same call: mmap2(0x6543, 1048576, 3, 0x0011, 9, 0) notice that they both have all the same values until you get to the last one... at which point the value is wrong... Apparently this only causes problems on some windows programs that one may try to execute, and not on others... So, where can I force this to get set? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Here's where it happens:
sys/i386/linux/linux_sysvec.c
static void
linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t *params)
{
args[0] = tf-tf_ebx;
args[1] = tf-tf_ecx;
args[2] = tf-tf_edx;
args[3] = tf-tf_esi;
args[4] = tf-tf_edi;
*params = NULL; /* no copyin */
}
You probably want to add:
args[5] = tf-tf_ebp;
so that it ends up in the syscallargs struct.
Yeah, I did that... it still doesn't work, tf_ebp isn't getting set... So
I'm thinking that either I have a glibc that's too old, or something else
is wrong...
For FreeBSD syscalls, we copy this from the top of stack for the number of
32 bit words specified in the syscall table in i386/trap.c:
if (params (i = narg * sizeof(int))
(error = copyin(params, (caddr_t)args, (u_int)i))) {
(narg comes from the syscall table).
OK, that gives me an idea...
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
RCS file: /home/ncvs/src/sys/i386/linux/linux_sysvec.c,v retrieving revision 1.99 diff -u -2 -r1.99 linux_sysvec.c --- linux_sysvec.c 4 Apr 2002 17:49:46 - 1.99 +++ linux_sysvec.c 24 Apr 2002 23:57:23 - @@ -711,4 +711,5 @@ args[3] = tf-tf_esi; args[4] = tf-tf_edi; + args[5] = tf-tf_ebp; *params = NULL; /* no copyin */ } Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message yeah, I did that already, and have been running with that since yesterday :-P still not working right though... I think it has something to do with that nargs thing... I'm checking that out now... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
yeah, I did that already, and have been running with that since yesterday
:-P
still not working right though... I think it has something to do with that
nargs thing... I'm checking that out now...
Ehh, apparently sy_narg is getting set correctly too:
struct linux_mmap2_args {
l_ulong addr; char addr_[PAD_(l_ulong)];
l_ulong len;char len_[PAD_(l_ulong)];
l_ulong prot; char prot_[PAD_(l_ulong)];
l_ulong flags; char flags_[PAD_(l_ulong)];
l_ulong fd; char fd_[PAD_(l_ulong)];
l_ulong pgoff; char pgoff_[PAD_(l_ulong)];
};
#define AS(name) (sizeof(struct name) / sizeof(register_t))
{ AS(linux_mmap2_args), (sy_call_t *)linux_mmap2 }
not that it really matters, the linux_prepsyscall is setting the params to
null:
static void
linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
*params){
args[0] = tf-tf_ebx;
args[1] = tf-tf_ecx;
args[2] = tf-tf_edx;
args[3] = tf-tf_esi;
args[4] = tf-tf_edi;
args[5] = tf-tf_ebp;
*params = NULL; /* no copyin */
}
so the code in syscall2 will not even bother to try to copy in the args...
it just uses whatever linux_prepsyscall tells it to use, and completely
ignores nargs... at least as far as I can tell...
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Alright, so I got tired of trying to figure out if glibc is doing something wierd or wrong so I downloaded the source for it, and I'm looking at it now... (for version 2.2.2 which is what we have on FreeBSD's linux_base-7) and here's what I'm seeing: pushl %ebp pushl %ebx pushl %esi pushl %edi movl OFFLO(%esp), %edx movl OFFHI(%esp), %ecx testl $0xfff, %edx jne L(einval) shrdl $12, %ecx, %edx /* mmap2 takes the offset in pages. */ shrl $12, %ecx jne L(einval) movl %edx, %ebp So above I'm seeing the offset arg get into register %ebp, which is what we expect... movl ADDR(%esp), %ebx movl LEN(%esp), %ecx movl PROT(%esp), %edx movl FLAGS(%esp), %esi movl FD(%esp), %edi Then I'm seeing all the other args getting put into the registers they belong in... (which matches up with our linux_prepsyscall() function) movl $SYS_ify(mmap2), %eax /* System call number in %eax. */ /* Do the system call trap. */ L(do_syscall): int $0x80 Now I'm seeing the int 0x80 trap /* Restore registers. */ popl %edi popl %esi popl %ebx popl %ebp So, as far as I can tell, this version of glibc is doing the Right Thing, and the ebp register is getting messed up somewhere along the line in either the assembly code that handles the 0x80 trap in FreeBSD, or in syscall2 (I think it's probably the asm that handles the 0x80 trap)... Can anyone confirm this? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are making it in... I checked this because the sixth argument to linux_mmap2() in truss was showing 0x6, but when I printed out that arg from the kernel, it was showing 0x0. Am I correct here? Ken Yes. According to http://john.fremlin.de/linux/asm/, linux used to parse only 5 args but now it parses six. Try adding: args[5] = tf-tf_ebp; I don't think that arg is there: Apr 23 10:36:13 ken /kernel: tf-tf_ebp = -1077938040 Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Erm, since everyone managed to HIJACK my sshd thread! ;)
PLEASE commit this :-) It's so annoying. Ken On Tue, 23 Apr 2002, Jordan Hubbard wrote: I'm going to commit the following in 48 hours unless someone can convince me that it's a good idea for FreeBSD to be the odd-OS out with respect to this behavior: Index: sshd_config === RCS file: /home/ncvs/src/crypto/openssh/sshd_config,v retrieving revision 1.4.2.6 diff -u -r1.4.2.6 sshd_config --- sshd_config 28 Sep 2001 01:33:35 - 1.4.2.6 +++ sshd_config 23 Apr 2002 18:38:01 - @@ -48,8 +48,8 @@ PasswordAuthentication yes PermitEmptyPasswords no -# Uncomment to disable s/key passwords -#ChallengeResponseAuthentication no +# Comment out to enable s/key passwords +ChallengeResponseAuthentication no # To change Kerberos options #KerberosAuthentication no To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are making it in... I checked this because the sixth argument to linux_mmap2() in truss was showing 0x6, but when I printed out that arg from the kernel, it was showing 0x0. Am I correct here? Ken Yes. According to http://john.fremlin.de/linux/asm/, linux used to parse only 5 args but now it parses six. Try adding: args[5] = tf-tf_ebp; I don't think that arg is there: Apr 23 10:36:13 ken /kernel: tf-tf_ebp = -1077938040 Ken My guess is that we're not doing something we should be doing in int0x80_syscall in order to get that last arg. But I do not have enough x86 knowledge to understand how the trapframe is constructed, so I cannot tell what needs to be done. Perhaps somebody with more x86 fu can help. Sorry, Crap, I don't know what's going on either, I was just looking at the asm in src/sys/i386/i386/exception.s, but I'm not very good with asm either, Can anyone help? I'm cross-posting to -current since nobody on hackers or emulation is able to help. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Kenneth Culver writes:
OK, I found another problem, here it is:
static void
linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
*params)
{
args[0] = tf-tf_ebx;
args[1] = tf-tf_ecx;
args[2] = tf-tf_edx;
args[3] = tf-tf_esi;
args[4] = tf-tf_edi;
*params = NULL; /* no copyin */
}
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are
making it in... I checked this because the sixth argument to linux_mmap2() in
truss was showing 0x6, but when I printed out that arg from the kernel, it
was showing 0x0. Am I correct here?
Ken
Yes. According to http://john.fremlin.de/linux/asm/, linux used to
parse only 5 args but now it parses six. Try adding:
args[5] = tf-tf_ebp;
Drew
OK, I THINK I found what calls the actual kernel syscall handler, and
sets it's args first, but I'm not sure:
from linux_locore.s
NON_GPROF_ENTRY(linux_sigcode)
call*LINUX_SIGF_HANDLER(%esp)
lealLINUX_SIGF_SC(%esp),%ebx/* linux scp */
movlLINUX_SC_GS(%ebx),%gs
movl%esp, %ebx /* pass sigframe */
push%eax/* fake ret addr */
movl$LINUX_SYS_linux_sigreturn,%eax /* linux_sigreturn() */
int $0x80 /* enter kernel with args
*/
0: jmp 0b
ALIGN_TEXT
I think the stuff above copies the args, and whatnot, but I'm not really
sure where it does this exactly...
It calls LINUX_SIGF_HANDLER, which then calls %esp's sf_handler function.
That is where I draw a blank, I don't know which function this is calling,
and can't find where it's being set. I think this might be what I want to
change though. :-P
Does anyone who actually knows assembly have any ideas?
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
To me, it looks like mmap2 takes an offset that's a page index, rather than a byte position. Since linux passes the offset with a 32-bit long, rather than a 64-bit off_t like we do, they need to do this in order to be able to map offsets larger than 4GB into a file. For linux_mmap2, I'd think we want to do roughly the same things as linux_mmap, but with bsd_args.pos = ctob((off_t)linux_args.pos) Drew AHH, ok I was wondering where PAGE_SHIFT was for FreeBSD. I guess ctob does what I need it to. I think that's probably why it still wasn't working yet... I think it also has to be page aligned before you pass it in though, I have to look at linux's do_mmap_pgoff() (I think that's the right function name) to see if it's expecting an already page-aligned arg, or if it's aligning it before it uses it. Thanks Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
AHH, ok I was wondering where PAGE_SHIFT was for FreeBSD. I guess ctob does what I need it to. I think that's probably why it still wasn't working yet... I think it also has to be page aligned before you pass it in though, I have to look at linux's do_mmap_pgoff() (I think that's the right function name) to see if it's expecting an already page-aligned arg, or if it's aligning it before it uses it. The name implies that do_mmap_pgoff() takes page-shift'ed args. An offset specified as a page-shift is page-aligned by definition. Eg, when you call ctob(pgoff) this turns out to be (pgoff PAGE_SHIFT) bytes. Drew That makes sense, regular linux mmap seems to expect the offset to be in bytes (from linux's mmap): ret = do_mmap_pgoff(file, addr, len, prot, flag, offset PAGE_SHIFT); Where linux's mmap2 does this: error = do_mmap_pgoff(file, addr, len, prot, flags, pgoff); so this looks to me like do_mmap_pgoff expects a page-aligned offset, meaning that the difference between a regular linux mmap, and linux's mmap2 is that mmap expects bytes, and mmap2 expects a page offset instead... even more is that linux's old_mmap (the one that we actually emulate in linux_mmap(), calls do_mmap2 with these args: err = do_mmap2(a.addr, a.len, a.prot, a.flags, a.fd, a.offset PAGE_SHIFT); so, I'll just do the ctob() and see what happens. :-) Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
On Monday 22 April 2002 06:29 am, you wrote: Kenneth Culver wrote: So what it looks like to me is that mmap2 expects an offset that's already page-aligned (I'm not sure if this is the right way to say it), where mmap doesn't. the FreeBSD code in the linuxulator basically just takes the offset that is passed in with the linux mmap, and uses that to call FreeBSD's mmap (the kernel version, not the one called from userland). So basically I'm kinda stuck as to what to do to implement linux's mmap2. The only thing I can think of is to implement a FreeBSD mmap2 that basically assumes that the offset passed in is already page aligned or whatever, and just uses it, and then have linux_mmap2() just call the FreeBSD mmap2(). Any ideas? This is too much work. Basically, it just wants to bitch when the offset is not page aligned, and then call the old mmap if it doesn't bitch. OK, I think I can do that, thanks for the help. Will anyone be interested in patches when/if I get this working? I also implemented ftruncate64 (which just calls ftruncate). Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
Basically, it just wants to bitch when the offset is not page aligned, and then call the old mmap if it doesn't bitch. Basically I misunderstood what the linux mmap2 was doing, it recieves an offset as a number of pages, not as bytes, so by definition it's already page aligned. All I have to do is convert the number of pages to a number of bytes and pass it along to FreeBSD's mmap. Thanks! Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: implementing linux mmap2 syscall
On Monday 22 April 2002 10:06 am, you wrote:
Kenneth Culver writes:
static inline unsigned long do_mmap(struct file *file, unsigned long
addr,
..
ret = do_mmap_pgoff(file, addr, len, prot, flag, offset
PAGE_SHIFT); out:
return ret;
}
This is what mmap2 does:
andstatic inline long do_mmap2(
unsigned long addr, unsigned long len,
unsigned long prot, unsigned long flags,
unsigned long fd, unsigned long pgoff)
...
error = do_mmap_pgoff(file, addr, len, prot, flags, pgoff);
So what it looks like to me is that mmap2 expects an offset that's
already page-aligned (I'm not sure if this is the right way to say it),
where mmap doesn't. the FreeBSD code in the linuxulator basically just
takes the offset
To me, it looks like mmap2 takes an offset that's a page index, rather
than a byte position. Since linux passes the offset with a 32-bit
long, rather than a 64-bit off_t like we do, they need to do this in
order to be able to map offsets larger than 4GB into a file.
For linux_mmap2, I'd think we want to do roughly the same things as
linux_mmap, but with bsd_args.pos = ctob((off_t)linux_args.pos)
Drew
OK, I found another problem, here it is:
static void
linux_prepsyscall(struct trapframe *tf, int *args, u_int *code, caddr_t
*params)
{
args[0] = tf-tf_ebx;
args[1] = tf-tf_ecx;
args[2] = tf-tf_edx;
args[3] = tf-tf_esi;
args[4] = tf-tf_edi;
*params = NULL; /* no copyin */
}
Basically, linux_mmap2 takes 6 args, and this looks here like only 5 args are
making it in... I checked this because the sixth argument to linux_mmap2() in
truss was showing 0x6, but when I printed out that arg from the kernel, it
was showing 0x0. Am I correct here?
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
implementing linux mmap2 syscall
Hi,
I have recently been trying to implement the linux mmap2 syscall into our
linuxulator, and I have run into a little problem.
I looked at the code that was used to implement the regular linux_mmap
syscall, and I've also looked in the linux kernel at the code that they use
for mmap and mmap2. Basically this is in the linux kernel:
This is what mmap does in linux...
static inline unsigned long do_mmap(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot,
unsigned long flag, unsigned long offset)
{
unsigned long ret = -EINVAL;
if ((offset + PAGE_ALIGN(len)) offset)
goto out;
if (!(offset ~PAGE_MASK))
ret = do_mmap_pgoff(file, addr, len, prot, flag, offset PAGE_SHIFT);
out:
return ret;
}
This is what mmap2 does:
andstatic inline long do_mmap2(
unsigned long addr, unsigned long len,
unsigned long prot, unsigned long flags,
unsigned long fd, unsigned long pgoff)
{
int error = -EBADF;
struct file * file = NULL;
flags = ~(MAP_EXECUTABLE | MAP_DENYWRITE);
if (!(flags MAP_ANONYMOUS)) {
file = fget(fd);
if (!file)
goto out;
}
down_write(current-mm-mmap_sem);
error = do_mmap_pgoff(file, addr, len, prot, flags, pgoff);
up_write(current-mm-mmap_sem);
if (file)
fput(file);
out:
return error;
}
So what it looks like to me is that mmap2 expects an offset that's already
page-aligned (I'm not sure if this is the right way to say it), where mmap
doesn't. the FreeBSD code in the linuxulator basically just takes the offset
that is passed in with the linux mmap, and uses that to call FreeBSD's mmap
(the kernel version, not the one called from userland). So basically I'm
kinda stuck as to what to do to implement linux's mmap2. The only thing I can
think of is to implement a FreeBSD mmap2 that basically assumes that the
offset passed in is already page aligned or whatever, and just uses it, and
then have linux_mmap2() just call the FreeBSD mmap2(). Any ideas?
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
more on mmap2
Alright, sorry for the cross-post, not sure where to send this. I THINK I got linux's mmap2 working, but for some reason, the program I'm testing with (the linux version of winex, the one that runs all those neat windows directx 8 games ;-) ) still does this (from truss) linux_mmap2(0x6543,0x10,0x0,0x22,0x,0x6) = 1698889728 (0x6543) linux_mmap2(0x6543,0x10,0x3,0x11,0x9,0x6) = 1698889728 (0x6543) linux_rt_sigprocmask(0x0,0x28150c00,0x286b2b70,0x8) = 0 (0x0) write(4,0x286b2c08,64) = 64 (0x40) read(0x5,0x286b2c08,0x40)= 64 (0x40) linux_rt_sigprocmask(0x2,0x286b2b70,0x0,0x8) = 0 (0x0) close(9) = 0 (0x0) linux_rt_sigprocmask(0x0,0x28150c00,0x286b2c78,0x8) = 0 (0x0) writev(0x4,0x286b2c38,0x2) = 98 (0x62) read(0x5,0x286b2d14,0x40)= 64 (0x40) linux_rt_sigprocmask(0x2,0x286b2c78,0x0,0x8) = 0 (0x0) mprotect(0x6543,0x10,0x7)= 0 (0x0) linux_rt_sigprocmask(0x0,0x28150c00,0x286b2c90,0x8) = 0 (0x0) write(4,0x286b2d20,64) = 64 (0x40) read(0x5,0x286b2d20,0x40)= 64 (0x40) linux_rt_sigprocmask(0x2,0x286b2c90,0x0,0x8) = 0 (0x0) linux_rt_sigprocmask(0x0,0x28150c00,0x286b2c78,0x8) = 0 (0x0) write(4,0x286b2d10,64) = 64 (0x40) read(0x5,0x286b2d10,0x40)= 64 (0x40) linux_rt_sigprocmask(0x2,0x286b2c78,0x0,0x8) = 0 (0x0) close(6) = 0 (0x0) linux_mmap2(0x0,0x12,0x0,0x22,0x,0x6) = 678707200 (0x28744000) munmap(0x28744000,0xc000)= 0 (0x0) munmap(0x2886,0x4000)= 0 (0x0) mprotect(0x2875,0x1,0x7) = 0 (0x0) linux_rt_sigprocmask(0x0,0x28150c00,0x286b2ca4,0x8) = 0 (0x0) write(4,0x286b2d40,64) = 64 (0x40) read(0x5,0x286b2d40,0x40)= 64 (0x40) linux_rt_sigprocmask(0x2,0x286b2ca4,0x0,0x8) = 0 (0x0) linux_rt_sigprocmask(0x0,0x28150c00,0x286b2ca4,0x8) = 0 (0x0) write(4,0x286b2d40,64) = 64 (0x40) read(0x5,0x286b2d40,0x40)= 64 (0x40) linux_rt_sigprocmask(0x2,0x286b2ca4,0x0,0x8) = 0 (0x0) linux_rt_sigprocmask(0x0,0x28150c00,0x286b2ca4,0x8) = 0 (0x0) write(4,0x286b2d40,64) = 64 (0x40) read(0x5,0x286b2d40,0x40)= 64 (0x40) linux_rt_sigprocmask(0x2,0x286b2ca4,0x0,0x8) = 0 (0x0) linux_open(/,0x8000,00)= 6 (0x6) linux_ioctl(0x6,0x82187201,0x28391024) ERR#22 'Invalid argument' close(6) = 0 (0x0) linux_stat64(0x286b23f0,0x286b2274,0x2813c568) = 0 (0x0) linux_open(/,0x18800,00) = 6 (0x6) linux_fstat64(0x6,0x286b2274,0x0)= 0 (0x0) linux_fcntl64(0x6,0x2,0x1) = 0 (0x0) linux_getdents64(0x6,0x286b2148,0x110) = 252 (0xfc) linux_getdents64(0x6,0x286b2148,0x110) = 252 (0xfc) linux_getdents64(0x6,0x286b2148,0x110) = 264 (0x108) linux_getdents64(0x6,0x286b2148,0x110) = 60 (0x3c) linux_getdents64(0x6,0x286b2148,0x110) = 0 (0x0) close(6) = 0 (0x0) linux_open(/,0x8000,00)= 6 (0x6) linux_ioctl(0x6,0x82187201,0x28391024) ERR#22 'Invalid argument' close(6) = 0 (0x0) linux_stat64(0x286b23f0,0x286b2274,0x2813c568) = 0 (0x0) linux_open(/,0x18800,00) = 6 (0x6) linux_fstat64(0x6,0x286b2274,0x0)= 0 (0x0) linux_fcntl64(0x6,0x2,0x1) = 0 (0x0) linux_getdents64(0x6,0x286b2148,0x110) = 252 (0xfc) linux_getdents64(0x6,0x286b2148,0x110) = 252 (0xfc) linux_getdents64(0x6,0x286b2148,0x110) = 264 (0x108) linux_getdents64(0x6,0x286b2148,0x110) = 60 (0x3c) linux_getdents64(0x6,0x286b2148,0x110) = 0 (0x0) close(6) = 0 (0x0) linux_rt_sigprocmask(0x0,0x28150c00,0x286b2ce0,0x8) = 0 (0x0) write(4,0x286b2d74,64) = 64 (0x40) read(0x5,0x286b2d74,0x40)= 64 (0x40) linux_rt_sigprocmask(0x2,0x286b2ce0,0x0,0x8) = 0 (0x0) exit(0x0) process exit, rval = 0 this is the end of the truss output, can anyone tell me if anything in this truss output looks like it would cause the program to exit without doing anything? (this is what happens, it doesn't do ANYTHING at all Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Advanced tuning advice
Yes, but every time I've seen those brought up, the high-level hackers here say Don't do that. :) If we could get a definitive answer on acceptable flags, I'll put it in the FAQ. Basically (although I'm not a high-level hacker) what I've gathered is that -O optimization above -O (without a numbeR) isn't supported because there are known bugs in gcc opts above -O (and it's questionable whether or not they actually improve performance). Also, I know in a lot of cases the -march opts don't really do much either. In some cases doing -march=pentium actually produces faster code on current systems than doing -march=pentiumpro (or -march=i686, these are the same thing). So basically my recommendation is that no matter what you hear from linux people (just saw an article on slashdot, and the guy said he compiled the whole gentoo linux system with -march=i686, which really doesn't increase performance much ) say about these opts, they don't really help. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
I guess it's possible to change over entirely. That would mean we would loase a.out support because the GNU tools are becoming incapable of supporting a.out (all machines we run on are Linux machines syndrome). If we really wanted to avoid problems like this in the future, we'd just scrap FreeBSD entirely, and go to Linux, a bit at a time, starting with ELF, then DWARF2 exceptions, and then the Linux ABI instead of the FreeBSD ABI, and then all of Linux, a piece at a time. At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out binaries lying around, but FreeBSD's default binary format has been ELF for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should entirely switch over to the regular gnu toolchain, but is it really necessary to keep supporting a.out? Just my $0.02 Ken PS: If I sound annoyed, it's because it's sometimes annoying to have your toolchain controlled by someone with an interest in a product that competes with yours; that works for people competing with Microsoft products on Microsoft platforms with a need to use Microsoft tools, and it applies to Cygnus being owned by RedHat and them controlling the FreeBSD tools. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out binaries lying around, but FreeBSD's default binary format has been ELF for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should entirely switch over to the regular gnu toolchain, but is it really necessary to keep supporting a.out? Just my $0.02 Rather than offer $0.02, send the patch. Well, I was just asking if it is necessary, I'd make a patch if there was interest. My mail was asking if there is interest. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
We aren't changing this for GCC 2.95 in 5-CURRENT. PEROID. There is zero reason for subjecting users to this ABI change for what would be gained. If you want to do something productive, submit patches that Bmake GCC 3.1 (which move us to Dwarf2 unwinding as a product). Oh ok, that's another story altogether... If nobody has gotten to it by the May timeframe I'll do it. I've been looking for a way to contribute to the FreeBSD project anyway. Right now I'm working nearly 40 hrs a week and going to college full-time, so I don't really have time to do anything else. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out binaries lying around, but FreeBSD's default binary format has been ELF for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should entirely switch over to the regular gnu toolchain, but is it really necessary to keep supporting a.out? Just my $0.02 The switchover is not trivial. You're asking someone to do work for something that's not really valuable to them. There are certain boot code features that require the use of a.out kernels; this is less an issue than it was, but there were a number of things lost when we went to the new loader that are important for embedded environments. Cross-building for older platforms (not as big an issue, IMO). Other reasons I haven't even thought of yet 8-). Yeah, I was just wondering if there were issues making us keep a.out stuff in FreeBSD aside from the I wanna run 2.2.x programs issue. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
(ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
/usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
demand paged dynamically linked executable
Now, if you'd like to talk Netscape into building a version intended for
a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
old...
I didn't realize anyone still used netscape 4.x. It's so disgustingly
unstable and slow.
Ken
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
#include rehash.h, see the thread we had on this a few weeks back on -chat. OK, I'll look, but I disagree... Mozilla runs flawlessly for me, and renders much faster than netscape, however it loads really slow. Opera runs nicely too, although it's linux only. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
It's less slow and much more reliable than mozilla and remains the only available browser that can access most of the sites I need to access. That's odd, I've never had any mozilla problems. All I know is that it doesn't crash on sites that Netscape crashes on (anything java) and for me it runs much faster than netscape. It loads slower, but renders pages much faster, and I tend to load my browser once per day, and just leave it on. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
That's odd, I've never had any mozilla problems. All I know is that it doesn't crash on sites that Netscape crashes on (anything java) and for me it runs much faster than netscape. It loads slower, but renders pages much faster, and I tend to load my browser once per day, and just leave it on. Anyway, this is way OT, so that was my last message about it. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
cd /usr/src/gnu/usr.bin/cc make make install On Wed, 13 Mar 2002, Martin Blapp wrote: Kris, fixes things, or at least identify a list of possible changes which others can test. How can I compile gcc without doing a make world ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Where are the TCP patches for 4.4?
If you want, I can make you some patches, I think I still remember when they went in... however I can't do any more than that... and I suspect since you're one of the developers, you already have a CVS repository and can do it yourself :-D Ken On Fri, 8 Mar 2002, Julian Elischer wrote: I remember someone saying that they were going to make a repository for patches for releases. In particular I[m looking at teh TCP patches that fixed the slow transfers in some situations. Thes changes were put in before 4.5 so I want to find them to upgrade some production 4.4 machines. I have the diffs for 4.4p9 but they seem to be only security fixes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.5-RELEASE upgrade..didnt??
did u do a config -r on your kernel config file? if not it might not pick up some of the new stuff. Ken On Mon, 4 Mar 2002, Geoff Mohler wrote: Ok..dumb question alert. (fair warning) I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded as well. Went in, and did a make on my config file from 4.3..and rebooted (made sure the new kernel was in / as well). Uname reports a 4.3 system..etc..etc..etc. What'd I miss? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
I have a small problem. I work for software development company and write daemons and console tools for Unix. My boss wants everything to be written in C++, because he thinks C++ is cool. I prefer C for such tasks, but I cannot really put good arguments of why and where C++ can be worse than C. I know many of you prefer C too. Can you please explain some disadvantages of C++ comparing to C ? Is it slower, does it produce less effective code, why is it like that, etc ... or please direct me to some articles where this can be explained. My main problem with C++ is that it adds a lot of overhead, and it's slow. Also, it drives me nuts when people code in C++ and write all kinds of classes when using classes for certain things just doesn't make sense, and makes the code much more convoluted. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
The code itself may be fast, but programs written in c++ tend to link to a lot of shared libs, which in itself can be pretty slow. Ken On Tue, 5 Mar 2002, Martin Ankerl wrote: My main problem with C++ is that it adds a lot of overhead, and it's slow. Well written C++ code can be very fast, have a look at http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html and http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html and http://www.oonumerics.org/blitz/ Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Well, that too, I guess I was just using KDE as an example of something being extremely slow due to a lot of libs being loaded. Ken On Tue, 5 Mar 2002, Raymond Wiker wrote: Kenneth Culver writes: The code itself may be fast, but programs written in c++ tend to link to a lot of shared libs, which in itself can be pretty slow. That's *not* unique to C++. On my machine, /usr/lib contains 73 shared libs, and these are mainly C libraries. If you want arguments against C++, try any of these: C++ programs use a *lot* of header files, and these do in general cause more work for the compiler than do the C header files. This boils down to noticeably longer compile times. C++ is a *much* larger language, with *much* more complicated semantics and behaviour. A large proportion of C++ programmers do not know the language well enough that they should be allowed to program in it. -- Raymond WikerMail: [EMAIL PROTECTED] Senior Software Engineer Web: http://www.fast.no/ Fast Search Transfer ASA Phone: +47 23 01 11 60 P.O. Box 1677 Vika Fax: +47 35 54 87 99 NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60 Try FAST Search: http://alltheweb.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.5-RELEASE upgrade..didnt??
How exactly did you upgrade? did you cvsup your sourcecode and then recompile from there? Ken On Tue, 5 Mar 2002, Geoff Mohler wrote: No, still have this from uname -a: 4.3-RELEASE FreeBSD 4.3-RELEASE #3: On Tue, 5 Mar 2002, Kenneth Culver wrote: did u do a config -r on your kernel config file? if not it might not pick up some of the new stuff. Ken On Mon, 4 Mar 2002, Geoff Mohler wrote: Ok..dumb question alert. (fair warning) I just did a 4.3 to 4.5 upgrade, and made sure the sys source was upgraded as well. Went in, and did a make on my config file from 4.3..and rebooted (made sure the new kernel was in / as well). Uname reports a 4.3 system..etc..etc..etc. What'd I miss? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message --- Geoff Mohler To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
I think what I was trying to say is that a lot of C++ programmers will obfuscate their code by using features of the language that don't fit with what they were trying to accomplish. Ken On Tue, 5 Mar 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Kenneth Culver [EMAIL PROTECTED] writes: : I have a small problem. I work for software development company and : write daemons and console tools for Unix. My boss wants everything to be : written in C++, because he thinks C++ is cool. I prefer C for such : tasks, but I cannot really put good arguments of why and where C++ can : be worse than C. I know many of you prefer C too. Can you please explain : some disadvantages of C++ comparing to C ? Is it slower, does it produce : less effective code, why is it like that, etc ... or please direct me to : some articles where this can be explained. : : My main problem with C++ is that it adds a lot of overhead, and it's slow. : Also, it drives me nuts when people code in C++ and write all kinds of : classes when using classes for certain things just doesn't make sense, and : makes the code much more convoluted. C++ doesn't add noticable overhead and isn't slow, unless you are a dumbass about how you write it. All languages give you plenty of ways to write speghetti fortran code :-). C++ gives you a number of ways to obfuscate. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
This is a serious concern for console tools, which are interacting with humans, which are capable of providing commands much faster than a 1.5GHz processor can accept and dispose of them... sorry I missed this downside in my first response. I'm not sure if you are being sarcastic or not, but if you are, it is definitely not appreciated. C code is generally easier to make more simple than C++. That said, gui code is probably better written in C++ since the whole idea of objects lends itself to that. However, daemons/console based progs don't really have any real reason to be written in C++ becuase that usually adds a lot of code that doesn't need to be there, such as using classes to do things that don't lend themselves to that. Geez... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Why are you being so sarcastic? Everyone here is assuming that it's harder to write C++ code, so you should only use it if necessary. It isn't necessary to use it for something like a daemon. Ken On Tue, 5 Mar 2002, Terry Lambert wrote: Steve B. wrote: I take a simplistic view after years of C++. C++ is good for large projects that need to be maintained into the future. Then the advantages of OO starts to kick in. For small projects that won't change much then C is the better choice IMO. Wow. Forgot this disadvantage of C++, too. Yeah, it's difficult to write code that someone else couldn't come in and maintain after it was done. This means that the normal rules about write important code and you have a job forever no longer apply. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
Because that underlying assumption is false, and I'm making fun of it. Well, that in itself is wrong. C++ code IS harder to write and write correctly and effeciently, as I would assume it is for any OO language. I'm not saying it can't be done, but generally speaking based on the Open source and commercial products I've seen, the ones that are written in C++ suffer from more bloat and run slower. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
I do agree that when the extra features of C++ are used this often results in bloated programs but this can at least in part be blamed on insufficiently skilled programmers. Note that C++ is not really an OO language. It is probably better to call it a language with support for object-oriented programming (as well as support for other programming styles.) I'll agree to that... :-D It's basically what I've been trying to say. That and if he's using gcc to compile, he might not get completely un-buggy code when he compiles c++ apps. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
I'm not saying it can't be done, but generally speaking based on the Open source and commercial products I've seen, the ones that are written in C++ suffer from more bloat and run slower. A trout is a fish. Therefore all fish are trout. I think you just failed set theory... ;^). Uhh, ok... Not that this had anything to do with set theory, although I see you were trying to be funny... Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: strange TCP slowness...
As far as I know, this is a problem that was fixed in -STABLE sometime in the last month or 2. If I were you I'd upgrade to 4.5 when it comes out and see if that solves the problem. Ken On Fri, 25 Jan 2002, Dmitry Mottl wrote: Hi, All Sorry, for posting a big dump, but it is needed for understanding the problem. I have very slow tcp connection between two computers on the same LAN This computers uses FreeBSD 4.4 GENERIC kernel The problem only occurs when I try to connect to FTP on host A There are NO OTHER problems mentioned I have good performance when I use ftp client on A (both PASSIVE ON and PASSIVE OFF modes), but FTP connections to A are very poor. And I have good perfomance at host B in any cases besides when I connect A This is a TCPDUMP for and passive ftp transfer As you can see the transfer stops every 1 second!!! So the question is WHY?? All sysctl variables are identical I'm not using firewalls or traffic shappers I use ProFTPd 1.2.4 on server and /usr/bin/ftp on client Host A: ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xd400-0xd41f irq 11 at device 11.0 on pci0 Host B: xl0: 3Com 3cSOHO100-TX OfficeConnect port 0xde80-0xdeff mem 0xffeffe80-0xffeffeff irq 9 at device 11.0 on pci0 so A is SERVER and B is CLIENT === 16:25:04.598824 CLIENT..1041 SERVER.1282: S 3460943278:3460943278(0) win 16384 mss 1460,nop,wscale 0,nop,nop,timestamp 294830 0 (DF) 16:25:04.599006 SERVER.1282 CLIENT..1041: S 1254154146:1254154146(0) ack 3460943279 win 17376 mss 1460,nop,wscale 0,nop,nop,timestamp 1749041 294830 (DF) 16:25:04.599372 CLIENT..1041 SERVER.1282: . ack 1 win 17376 nop,nop,timestamp 294830 1749041 (DF) 16:25:04.599662 CLIENT..1040 SERVER.ftp: P 33:46(13) ack 109 win 17376 nop,nop,timestamp 294830 1749041 (DF) [tos 0x10] 16:25:04.601325 SERVER.ftp CLIENT..1040: P 109:178(69) ack 46 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.602522 SERVER.1282 CLIENT..1041: . 1:1449(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.602857 SERVER.1282 CLIENT..1041: . 1449:2897(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.603957 SERVER.1282 CLIENT..1041: . 2897:4345(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.605193 SERVER.1282 CLIENT..1041: . 4345:5793(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.606415 SERVER.1282 CLIENT..1041: . 5793:7241(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.607643 SERVER.1282 CLIENT..1041: . 7241:8689(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.608887 SERVER.1282 CLIENT..1041: . 8689:10137(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.610125 SERVER.1282 CLIENT..1041: . 10137:11585(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.611337 SERVER.1282 CLIENT..1041: . 11585:13033(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.612569 SERVER.1282 CLIENT..1041: . 13033:14481(1448) ack 1 win 17376 nop,nop,timestamp 1749042 294830 (DF) 16:25:04.615273 CLIENT..1041 SERVER.1282: . ack 2897 win 15928 nop,nop,timestamp 294831 1749042 (DF) [tos 0x8] 16:25:04.615346 CLIENT..1041 SERVER.1282: . ack 2897 win 17376 nop,nop,timestamp 294832 1749042 (DF) [tos 0x8] 16:25:04.615417 CLIENT..1041 SERVER.1282: . ack 2897 win 17376 nop,nop,timestamp 294832 1749042 (DF) [tos 0x8] 16:25:04.616562 SERVER.1282 CLIENT..1041: . 14481:15929(1448) ack 1 win 17376 nop,nop,timestamp 1749043 294832 (DF) 16:25:04.617148 SERVER.1282 CLIENT..1041: . 15929:17377(1448) ack 1 win 17376 nop,nop,timestamp 1749043 294832 (DF) 16:25:04.619130 CLIENT..1041 SERVER.1282: . ack 2897 win 17376 nop,nop,timestamp 294832 1749042 (DF) [tos 0x8] 16:25:04.619299 CLIENT..1041 SERVER.1282: . ack 2897 win 17376 nop,nop,timestamp 294832 1749042 (DF) [tos 0x8] 16:25:04.619583 SERVER.1282 CLIENT..1041: . 2897:4345(1448) ack 1 win 17376 nop,nop,timestamp 1749043 294832 (DF) 16:25:04.621130 CLIENT..1041 SERVER.1282: . ack 4345 win 15928 nop,nop,timestamp 294833 1749043 (DF) [tos 0x8] 16:25:04.621417 SERVER.1282 CLIENT..1041: . 4345:5793(1448) ack 1 win 17376 nop,nop,timestamp 1749044 294833 (DF) 16:25:04.622983 CLIENT..1041 SERVER.1282: . ack 5793 win 15928 nop,nop,timestamp 294833 1749044 (DF) [tos 0x8] 16:25:04.623267 SERVER.1282 CLIENT..1041: . 5793:7241(1448) ack 1 win 17376 nop,nop,timestamp 1749044 294833 (DF) 16:25:04.623524 SERVER.1282 CLIENT..1041: . 17377:18825(1448) ack 1 win 17376 nop,nop,timestamp 1749044 294833 (DF) 16:25:04.625841 CLIENT..1041 SERVER.1282: . ack 7241 win 15928 nop,nop,timestamp 294833 1749044 (DF) [tos 0x8] 16:25:04.626119 SERVER.1282 CLIENT..1041: . 7241:8689(1448) ack 1 win 17376 nop,nop,timestamp 1749044 294833 (DF) 16:25:04.626159 CLIENT..1041 SERVER.1282: . ack 7241 win 17376 nop,nop,timestamp 294833 1749044 (DF) [tos 0x8] 16:25:04.626419 SERVER.1282 CLIENT..1041: .
Re: strange TCP slowness...
Yeah, I guess it could be packet collision or something... are you connecting the computers through a hub? Ken On Fri, 25 Jan 2002, Mike Silbersack wrote: On Fri, 25 Jan 2002, Dmitry Mottl wrote: Hi, All Sorry, for posting a big dump, but it is needed for understanding the problem. I have very slow tcp connection between two computers on the same LAN This computers uses FreeBSD 4.4 GENERIC kernel This is a TCPDUMP for and passive ftp transfer As you can see the transfer stops every 1 second!!! So the question is WHY?? All sysctl variables are identical I'm not using firewalls or traffic shappers Well, from this trace it's clear that packet loss is occuring; the 1 second delays are retransmit timeouts, nothing unexpected there. As far as I can tell from looking at the trace, the problem is not a fault in FreeBSD's tcp stack, but rather something hardware related. I'd suggest changing network cards on host A to see if that makes a difference. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Performance issue
If they're using gcc to compile then that doesn't really matter, last I heard gcc's optimizer wasn't that great, and didn't result in much faster code, but if the glibc people hand optimized stuff, I can see your point. Ken This means that Linux's glibc is using an i686 optimized bzero(), but the FreeBSD one is using an i386 optimized bzero(). Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IPFW module
On Friday 09 November 2001 02:12 am, you wrote: if you included options IPFIREWALL in your kernel, you don't need to kldload the module, and it may mess some things up if you do try to kldload it. This morning I've cvsuped to STABLE and put 'options IPFIREWALL' into my kernel configuration file. After installing all I try to 'kldload ipfw' which complains that ipfw module is already in kernel, but kldstat reports that module is being loaded! Then I've decided to kldunload it Kernel panic reboot! It is regular to kernel crash if ipfw is loaded as module, but why when it was build into kernel? In that case it would be good kldload/kldunload to exit! Why kldload loads module in case that it is compiled in kernel? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
