Re: if_fxp - the real point
On Sat, Mar 10, 2001 at 10:30:08AM -0600, Peter Seebach wrote: For that matter, is the fxp still the most-recommended driver on Alpha? It *never* has been the recommended driver on FreeBSD/Alpha. The fxp driver has had issues on Alpha for a long time. Andrew will fix something with it, then it breaks again for some, etc... DG has an Alpha, but I don't think he has ever turned it on. He certainly has never done and Alpha-specific fxp fixes that I am aware of. The `guaranteed to work on Alpha driver' is anything supported by the `de' driver, as that is what the built-in NIC is on older Alpha's so OS's have no choice but deal with them. After that, I would say any of the `xl' 3Com cards. Bill Paul tested his just about all his drivers on an Alpha when developing them. The really nice thing about the `xl' 3Com cards is they don't have the alignment requirements of most of the other NICs in existence. Thus you can get really good performance on the Alpha. Behind the `xl' 3Com cards, would be any DEC 21143 based NIC which is supported by Bill Paul's `dc' driver. The nice thing about `de' and `dc' cards is SRM recognizes them. I got the impression there were some alignment issues that might be cheaper to solve on i386 than Alpha. Both `xl' and `fxp' cards do not have strict alignment issues (which makes them very nice and reduces a memory copy). The problems with the `fxp' cards is simply how its driver works on the Alpha. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Porting NVidia linux kernel modules to FreeBSD
Hello! I'm quite interested in having true 3D hardware acceleration on my ASUS AGP-V3800Magic video card based on TNT2 M64 chip, while running XFree86-4.0.2 on FreeBSD 4.2-STABLE. I've been searching USENET, mail-archives, web, and all I was able to find was: * information on www.nvidia.com about binary XFree modules and kernel module (for linux only) * the source for linux kernel * binary XFree modules (replacing xfree's native 'nv' - 'nvidia') * people saying that there's some undergoing work about porting linux source to FreeBSD so it's possible to use proprietary nvidia's modules for XFree (oh gee, how happy I am with their module architecture) So, my question is, what's the current status of this initiative? Is there any pre-alphas or whatever I might try already? I will appreciate any information with regard to this subject. 10x. ./danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
Alexey Dokuchaev wrote: Hello! I'm quite interested in having true 3D hardware acceleration on my ASUS AGP-V3800Magic video card based on TNT2 M64 chip, while running XFree86-4.0.2 on FreeBSD 4.2-STABLE. AOL Me too /AOL 3D acceleration (or the lack thereof) is supposed to be one of the reasons why XFree 336 is still the standard version delivered for FreeBSD. I have not searched exactly how it is possible to have glx acceleration with 336 and NVidia boards, but Iwould be intersted to know if some how-to existed (I've switched to 4.0.x as this should have been the way to DRI and fully-supported, OS-independant, 3D acceleration) nevertheless, the NVidia "Linux kernel module" seems to be a encapsulation of their Win$$ driver, so as to be usable under Linux. Maybe the careful study of the source included in the "kernel module" can give some hints on how to do the same kind of wrapper for FreeBSD good luck -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: blow fish
I think Mark Murray is still sitting on the patch I did for this very thing. Check the -hackers mail archives. It was about 2-3 Months ago, so it may not even patch cleanly anymore against -CURRENT. I committed this today! Apologies for the delay. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Help!!! 2nd HD gone
Howdy, fbsd:~ uname -a FreeBSD playground 3.4-RELEASE FreeBSD 3.4-RELEASE #1: Sun Mar 26 16:56:35 PST 2000 root@:/usr/src/sys/compile/McKERNEL i386 From dmesg: CPU: Pentium/P55C (167.05-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 33554432 (32768K bytes) chip0: Intel 82439TX System Controller (MTXC) rev 0x01 on pci0.0.0 chip1: Intel 82371AB PCI to ISA bridge rev 0x01 on pci0.7.0 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.7.1 chip2: Intel 82371AB Power management controller rev 0x01 on pci0.7.3 wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc1 not found at 0x170 This makes me think the kernal is not seeing the controller at boot. from /sys/i386/conf/McKERNEL: controller wdc0at isa? port "IO_WD1" bio irq 14 controller wdc1at isa? port "IO_WD2" bio irq 15 from /usr/src/sys/i386/isa/isa.h: #define IO_WD1 0x1F0 /* Primary Fixed Disk Controller */ #define IO_WD2 0x170 /* Secondary Fixed Disk Controller */ wd2 aka D: aka /dev/hdc is visible from dos and I'm writing this from Slackware 7.0 mounted on /dev/hdc8. This from Slackware's /var/log/messages: Mar 7 13:28:39 playground kernel: hda: WDC AC24300L, 4112MB w/256kB Cache, CHS=524/255/63, UDMA Mar 7 13:28:39 playground kernel: hdc: WDC AC26400R, 6149MB w/512kB Cache, CHS=13328/15/63, (U)DMA I once had several slices on wd2s* mounted in /etc/fstab but that doesn't work today. I'm fairly this is something I broke in FreeBSD but can't discover where. I really don't want to re-install. I've tried various configurations in BIOS with no luck. I'm stumped. All suggestions welcome. TIA, MiKe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vnode_if.h inlining
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm writing a kernel module which uses the function VOP_OPEN. When I try to compile my module vnode_if.h complains: vnode_if.h:177: warning: inlining failed in call to `VOP_OPEN' binctl.c:35: warning: called from here vnode_if.h:206: warning: inlining failed in call to `VOP_CLOSE' What does this mean? Here is some extra info: The VOP_OPEN call: VOP_OPEN(vp, FREAD, p-p_ucred, p); vp = p-p_tracep Thanks, Evan Sarmiento ([EMAIL PROTECTED]) http://sekt7.org/es -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (SunOS) Comment: Made with pgp4pine 1.75-6 iEYEARECAAYFAjqr268ACgkQa7CFsJ0L22xh6QCeIBjboiqya4XVyGpXU7BTqWAE q5cAnAtOuLySFceXg6C/VU4hu7oDKZqB =F6Yi -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
3D acceleration (or the lack thereof) is supposed to be one of the reasons why XFree 336 is still the standard version delivered for FreeBSD. It is, at least for me. I've been waiting for XFree86 4.0.x to come up to the same FPS performance numbers since it came out. I have not searched exactly how it is possible to have glx acceleration with 336 and NVidia boards, but Iwould be intersted to know if some It's trivial. You just build the utah-glx port and make sure that you load the glx.so module from your XF86Config file. You don't need any wrappers or DRI stuff or anything. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On Sun, 11 Mar 2001, Jordan Hubbard wrote: 3D acceleration (or the lack thereof) is supposed to be one of the reasons why XFree 336 is still the standard version delivered for FreeBSD. It is, at least for me. I've been waiting for XFree86 4.0.x to come up to the same FPS performance numbers since it came out. So, are you saying that 3.3.6 performs better than 4.0.2? If this is true I might dump 4.0.2 and go for 3.3.6 (luckily there's server with ttf support builtin). -- WBR, Alexey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help!!! 2nd HD gone
On Sun, Mar 11, 2001 at 11:01:07AM -0800, [EMAIL PROTECTED] wrote: Howdy, fbsd:~ uname -a FreeBSD playground 3.4-RELEASE FreeBSD 3.4-RELEASE #1: Sun Mar 26 At first time, you must up to RELENG_3. Then, if it don't help, you must up to RELENG_4 (via RELEASE_4_0_0 or other, please see handbook and archive of -stable maillist). -- Rgdz,/"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED]X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with K6-2/500 CPU
hi all i can say, freebsd 3.1 to 4.2 is running stable and fine ;) on k6-2 400 and 500 !!! i am got it running here on my maschine. -- gruesse joerg "joerch" buechner mailto: [EMAIL PROTECTED] subject: i know fraggin nothin, bastich! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On 11-Mar-01 Alexey Dokuchaev wrote: On Sun, 11 Mar 2001, Jordan Hubbard wrote: It is, at least for me. I've been waiting for XFree86 4.0.x to come up to the same FPS performance numbers since it came out. So, are you saying that 3.3.6 performs better than 4.0.2? If this is true I might dump 4.0.2 and go for 3.3.6 (luckily there's server with ttf support builtin). Well, in 3d it is better because you can use Utah-GLX with 3.3.6 but not 4.x. In 3d 3.3.6 is worse because it doesn't accelerate 24bit displays (and maybe other aspects). DRI would be nice, but nVidia don't agree so the Linux foo would be next best. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
So, are you saying that 3.3.6 performs better than 4.0.2? If this is true Absolutely. At least 2X the frame rate using the same OpenGL app in each case. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Greater than 2GB per process
Hello, Could anybody advise me on the possiblity of having greater than 2GB per process on FreeBSD. I have tried increasing the limit beyond this and the kernel compiles successfully - however libc causes every process to segfault. I am assuming that just recompiling the C library wouldn't do the trick but perhaps someone could confirm this. Cheers, Ian Campbell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On Sun, 11 Mar 2001, Jordan Hubbard wrote: So, are you saying that 3.3.6 performs better than 4.0.2? If this is true Absolutely. At least 2X the frame rate using the same OpenGL app in each case. But, this is when using hw accel on 3.3.6 vs. software "accel" on 4.0.2, right, like it would be in case of nvidia cards? Contrary, it cant' be *that* bad if I carry out these test with card that fully supports DRI. right? //danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
From: Alexey Dokuchaev [EMAIL PROTECTED] Subject: Re: Porting NVidia linux kernel modules to FreeBSD Date: Mon, 12 Mar 2001 08:17:44 +0600 (NOVT) But, this is when using hw accel on 3.3.6 vs. software "accel" on 4.0.2, No. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On 12-Mar-01 Jordan Hubbard wrote: From: Alexey Dokuchaev [EMAIL PROTECTED] Subject: Re: Porting NVidia linux kernel modules to FreeBSD Date: Mon, 12 Mar 2001 08:17:44 +0600 (NOVT) But, this is when using hw accel on 3.3.6 vs. software "accel" on 4.0.2, No. What 3d acceleration can you do with X4 WRT OpenGL? I wasn't aware you could do any. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
But, this is when using hw accel on 3.3.6 vs. software "accel" on 4.0.2, No. Meaning, 3.3.6 + utah_glx outperforms by a factor of two 4.0.2 + DRI?! - danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel area libmish stuff
On Sat, 10 Mar 2001 21:37:28 -0800, Farooq Mela [EMAIL PROTECTED] wrote: Jordan DeLong wrote: I was thinking of just getting a sintable array and making a few simple functions, so the whole of libm doesn't need to be statically linked into the module (from my understanding, once loaded, this module wont ever get paged +out, and thus it'd be _bad_ for it to be big). Well, you can't do any FP stuff inside the kernel, as stated by others. But what you can do is use the fact that: sin(x) = x - (x^3)/3! + (x^5)/5! - (x^7)/7! ... Actually, whilst Taylor expansions are mathematically nice, they are generally a very poor implementation choice - primarily because they are infinite series and can be very slow to converge for large x. Trig functions are normally implemented as truncated Taylor series (you pick a finite expansion and tweak the co-efficients to minimise error), or ratios of polynomials. In both cases, the polynomials need to be `tuned' to suit the FP precision. If you do decide to go the fixed-point approach, remember that multiplication and division need fixups afterwards to re-align the binary point. (Multiplying two numbers with a 24 bit fraction gives a result with a 48 bit fraction). If you did pick a 24-bit fraction, you could probably pinch the co-efficients out of the `float' trig functions in msun. For a totally different approach, try Cordic algorithms. Cordic algorithms let you implement circular and hyperbolic functions (including exponential, log and sqrt) using add, subtract, shift and table lookup. (An n-bit result needs an n-entry x n-bit table, 2n shifts and 3n adds/subtracts). I know there was an article in October 1990 Dr Dobbs Journal and a web search should probably find plenty more. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On Mon, 12 Mar 2001, Alexey Dokuchaev wrote: But, this is when using hw accel on 3.3.6 vs. software "accel" on 4.0.2, No. Meaning, 3.3.6 + utah_glx outperforms by a factor of two 4.0.2 + DRI?! Or, even better, 4.0.2 + "suppose-we-managed-to-port-it nvidia kernel module" + nvidia binary 'nvidia' replacement module for XFree-4's 'nv' driver? I mean, will 336/utah be better?? //danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Greater than 2GB per process
* Ian Campbell [EMAIL PROTECTED] [010311 16:14] wrote: Hello, Could anybody advise me on the possiblity of having greater than 2GB per process on FreeBSD. I have tried increasing the limit beyond this and the kernel compiles successfully - however libc causes every process to segfault. I am assuming that just recompiling the C library wouldn't do the trick but perhaps someone could confirm this. It's not possible on the Intel archetecture with the current system, changing the current intel system to use 2GB processes would cost too much in terms of performance (64 bit values on a 32 bit system). At least that's what i've been told. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On Mon, 12 Mar 2001, Daniel O'Connor wrote: On 12-Mar-01 Alexey Dokuchaev wrote: That's what I thought, but Jordan's email really made me doubt that my vision of things is correct. Particulary, I don't quite understand this one: Statement #1: Utah-GLX doesn't direct render Statement #2: From man nv(4) of XFree-4.0.2- "The driver is fully accelerated, and provides support..." This means 'in 2D'. Oh, OK, got it now. 10x. ./me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Greater than 2GB per process
- Original Message - From: "Alfred Perlstein" [EMAIL PROTECTED] To: "Ian Campbell" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, March 11, 2001 23:41 Subject: Re: Greater than 2GB per process * Ian Campbell [EMAIL PROTECTED] [010311 16:14] wrote: Hello, Could anybody advise me on the possiblity of having greater than 2GB per process on FreeBSD. I have tried increasing the limit beyond this and the kernel compiles successfully - however libc causes every process to segfault. I am assuming that just recompiling the C library wouldn't do the trick but perhaps someone could confirm this. It's not possible on the Intel archetecture with the current system, changing the current intel system to use 2GB processes would cost too much in terms of performance (64 bit values on a 32 bit system). At least that's what i've been told. I know very little about how kernel or low level processor stuff works, but shouldn't we be able to do a 4GB process on a 32-bit system? The limitation of 2GB per process should only be an issue if there is some need to use signed numbers, right? Joe Gleason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On 2001-03-10 21:56 -0600, Peter Seebach [EMAIL PROTECTED] wrote: Out of idle curiousity, has the NIH syndrome died down enough that it might hypothetically be possible for the three major *BSD camps to cooperate on this kind of thing? Form an organization the purpose of which is to get access to driver docs *for all three systems*? An organization which can claim to represent 2N or 3N users, instead of N, *might* be able to get people to listen more closely... Especially if it maintained a page describing hardware and vendor relations, and a lot of people got in the habit of linking to it. Does Intel care if there's a page saying "Intel has refused to provide specs, so we are obliged to recommend Frobozz Magic Ethernet instead"? Probably not, but they *might*. More than they care about mutterings on mailing lists, certainly. Peter, This sounds like something that Daemon News might be able to help with. Are you interested in spending some time on it? Our staff is stretched very thin right now and can't really take on any more projects without additional volunteers. If you or another interested party has the time, though, I think that the attempt should be made and that Daemon News is the right umbrella for it. Greg -- Gregory S. Sutter The measure of a man is the way mailto:[EMAIL PROTECTED] he bears up under misfortune. http://www.daemonnews.org/--Plutarch hkp://wwwkeys.pgp.net/0x845DFEDD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: httpfs
On 2001-03-10 13:36 -0500, Robert Watson [EMAIL PROTECTED] wrote: On Sat, 10 Mar 2001, Kris Kennaway wrote: A few of us were talking on IRC tonight about how cool it would be to have an httpfs filesystem -- then it occurred to me we almost have this already, in the form of the (under-utilised) portalfs. Portalfs works by handing off everything to a userland daemon which handles the actual transaction request, so you could easily imagine extending it to provide an http method similar to the tcp method it currently has for initiating tcp connections. I need not remind you that file systems front-ending onto random protocols are a bad idea for a huge number of reasons :-). Could you give me the three biggest reasons, IYO? I don't seem to know any of them. Thanks! Greg -- Gregory S. Sutter Five million battered women in mailto:[EMAIL PROTECTED] this country, and I've always http://www.zer0.org/~gsutter/ eaten mine plain... hkp://wwwkeys.pgp.net/0x845DFEDD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Greater than 2GB per process
Alfred Perlstein ([EMAIL PROTECTED]) wrote: * Joseph Gleason [EMAIL PROTECTED] [010311 20:48] wrote: - Original Message - From: "Alfred Perlstein" [EMAIL PROTECTED] To: "Ian Campbell" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, March 11, 2001 23:41 Subject: Re: Greater than 2GB per process * Ian Campbell [EMAIL PROTECTED] [010311 16:14] wrote: Hello, Could anybody advise me on the possiblity of having greater than 2GB per process on FreeBSD. I have tried increasing the limit beyond this and the kernel compiles successfully - however libc causes every process to segfault. I am assuming that just recompiling the C library wouldn't do the trick but perhaps someone could confirm this. It's not possible on the Intel archetecture with the current system, changing the current intel system to use 2GB processes would cost too much in terms of performance (64 bit values on a 32 bit system). At least that's what i've been told. I know very little about how kernel or low level processor stuff works, but shouldn't we be able to do a 4GB process on a 32-bit system? The limitation of 2GB per process should only be an issue if there is some need to use signed numbers, right? Yes, we use signed numbers. Check the list archives, there's some pretty detailed discussions that explain why it's this way. Actually.. the kernel and userspace processes use the same address space and since the kernel take 1GB of the address apce, you then have 512MB allocated for the malloc pool and the rest is allocated to malloc, so techinically you can mmap 2.5GB of memory, but according to the manual page of mmap.. BUGS len is limited to 2GB. Mmapping slightly more than 2GB doesn't work, but it is possible to map a window of size (filesize % 2GB) for file sizes of slightly less than 2G, 4GB, 6GB and 8GB. The limit is imposed for a variety of reasons. Most of them have to do with FreeBSD not wanting to use 64 bit offsets in the VM system due to the extreme performance penalty. So FreeBSD uses 32bit page indexes and this gives FreeBSD a maximum of 8TB filesizes. It's actually bugs in the filesystem code that causes the limit to be further restricted to 1TB (loss of precision when doing blockno calculations). Another reason for the 2GB limit is that filesystem metadata can reside at negative offsets. asd We currently can only deal with page aligned file offsets. b To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
