Go Back   nV News Forums > Linux Support Forums > NVIDIA FreeBSD

Newegg Daily Deals

View Poll Results: Where do you stand in regards to AMD64 on BSD?
I use it and would like an nVidia driver! 16 88.89%
I'm considering using it. 1 5.56%
It's too new. I'll wait and see what Intel does. 0 0%
I'm waiting for AMD64-STABLE. 1 5.56%
Voters: 18. You may not vote on this poll

Reply
 
Thread Tools
Old 03-01-04, 08:52 PM   #13
SnapIT
Registered User
 
Join Date: Jun 2003
Posts: 154
Default

To clarify my earlier post, explaining the importance of per page permissions in the AM-64 implementation...

On IA32 if a page is writable it's also executable, meaning once the overflow happens you just have to find a way to make EIP point to the overflow area to execute your code. What AMD64 (and everyone else that's not IA32 compatible) does is include an extra security bit that allows you to set pages writable but not executable, so even though the overflow still happens and the app crashes there's no chance to execute code from the overflow. Userland programmers don't see any difference, the kernel is what manages the page permissions.
SnapIT is offline   Reply With Quote
Old 03-01-04, 09:14 PM   #14
J.F.
GeForce FX5600
 
Join Date: Dec 2003
Location: Arizona
Posts: 35
Send a message via AIM to J.F.
Default

Intel is planning to eventually release an AMD64 compatible chip based on both Xeon and Prescott cores later this year. You can get the manuals now off Intel's site. Intel calls it ia-32e and it implements all the AMD64 instruction and architecture changes other than the No-Execute bit (which they mark as reserved, so maybe it'll still make it into the final release).

Reading through the Intel docs is rather funny. First, they make it seem like this was all their idea and that it's just a coincidence that it happens to be compatible with AMD64. You won't find an acknowledgement of AMD anywhere in the manual. Second, they try very hard not to scare away their Itanium customers. ia-32e (AMD64) is NOT a 64 bit processor, rather, it's just an extension to 64 bit addresses. However, since the addresses are 64 bits long, the registers need to be 64 bits long too. And since the addresses are 64 bits long, you need 64 bit operations to do 64 bit pointer operations. In no way are you to believe that makes it a 64 bit processor competing with Itanium.

Linux went with the symbol x86-64 because Linus preferred that to AMD64. BSD went with AMD and used AMD64. Microsoft also went with AMD64 after Intel swore they'd NEVER make an AMD64 compatible chip. So MS is in the peculiar position of having 64 bit Windows software compiling with the AMD64 symbol which will run on Intel chips.

As far as load modules go, this is the closest I could find on the FreeBSD AMD64 mailing list -

Quote:
Date: Wed, 11 Feb 2004 12:39:50 -0800
From: Peter Wemm <peter@wemm.org>
Subject: Re: kld support
To: Petri Helenius <pete@he.iki.fi>, obrien@freebsd.org
Cc: freebsd-amd64@freebsd.org
Message-ID: <200402111239.50639.peter@wemm.org>
Content-Type: text/plain; charset="iso-8859-1"

On Wednesday 11 February 2004 01:01 am, Petri Helenius wrote:

>> Since the kld support for amd64 is pending, is there a way to compile
>> netgraph modules statically into the kernel to get for example
>> ng_ether support?
>>
>> I would also be happy to try out early code if such thing exists. (to
>> enable KLD) For the time being, I have a spare opteron box.


I have bad news and some good news on this front. I thought we might be
able to get away with a quick hack to binutils to get it to work.
Indeed, I've been able to produce .ko files that can be loaded and
almost even work. But thats the problem... almost.

Check out these lines in sys/conf/NOTES:
options NETGRAPH #netgraph(4) system
options NETGRAPH_ASYNC
options NETGRAPH_BPF
options NETGRAPH_BRIDGE
options NETGRAPH_CISCO
options NETGRAPH_ECHO
options NETGRAPH_ETHER
options NETGRAPH_FRAME_RELAY
options NETGRAPH_GIF
......[lots more]....
Thats how you chose what you want to compile in.

Anyway, the problem with binutils is subtle but massive. There is a
sanity check that prevents you producing shared libs without -fpic
mode. Because *everybody* knows that ld.so cannot guarantee that it
can load the library within the first 2GB of address space on linux, so
binutils enforces this policy. The problem though is that all the wold
is not linux. And there are legitimate reasons for doing this. One of
which is our kernel modules where we can provide those guarantees.

Anyway, removing the sanity check lets you produce them. BUT... because
those code paths have never been tested on linux, binutils neglects to
support the rest of the relocation types that would be needed, and none
of the linux folks have noticed. Binutils is a freaking nightmare to
try and work in, and it has me totally beaten on this one.

So, I thought.. since I can do something about the in-kernel linker,
perhaps I can add PIC mode support? The problem with that though is
that gcc says "-fPIC mode not implemented in kernel mode" and errors
out. There's no way in hell that I'm going to try and implement that
in gcc either, so plan B is a bust.

The good news though is that Plan C is possible. Plan C is to stop
using -shared for kernel modules and use a simple .o file, like linux
does. I think I can write code for the kld subsystem without too much
pain. And because linux does the same thing already, we dont have to
worry about treading on landmines in binutils/gcc, because that path
should be well trodden already.

We already produce these files in kmod.mk. If you have a look at the
obj dirs, we have:

ld -d -warn-common -r -d -o if_sl.kld if_sl.o slcompress.o
touch /home/src/sys/modules/if_sl/obj/export_syms
awk -f /home/src/sys/modules/if_sl/../../conf/kmod_syms.awk
if_sl.kld /home/src/sys/modules/if_sl/obj/export_syms | xargs -J%
objcopy % if_sl.kld
ld -Bshareable -d -warn-common -o if_sl.ko if_sl.kld
ld: if_sl.kld: relocation R_X86_64_32S can not be used when making a
shared object; recompile with -fPIC
..... ls obj/
-rw-r--r-- 1 root src 19608 Feb 11 12:32 if_sl.kld

That file was the immediate step prior to conversion to a .ko file, and
thats what we can load.

On another machine with the hacks to produce a .ko anyway, we have:
peter@hammer[12:37pm]/home/obj/home/src/sys/modules/if_sl-105> ls -l
if_sl.*
-rw-r--r-- 1 root wheel 19608 Feb 6 14:46 if_sl.kld
-rwxr-xr-x 1 root wheel 23179 Feb 6 14:46 if_sl.ko*
-rw-r--r-- 1 root wheel 15760 Feb 6 14:46 if_sl.o
-rw-r--r-- 1 root wheel 24668 Feb 6 14:46 if_sl.s

Also of note is that the .kld file is smaller than the .ko file.

So yes, there is light at the end of the tunnel. I think its time to
give up on binutils/gcc hacking and take the path of least resistence
and write some code that we control. The original reasons for having
-shared kernel object files are mostly obsolete these days. We dont
use the DT_NEEDED tags for dependency tracking anymore, for example.
I think we can actually get a superior system as a result.
-- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Hope it helps answer your question. If you need more info, I suggest emailing Peter.
J.F. is offline   Reply With Quote
Old 03-01-04, 09:16 PM   #15
shupienis
Registered User
 
Join Date: Mar 2004
Location: Pittsburgh
Posts: 10
Default

Quote:
Originally posted by SnapIT

IE that means that every driver has to fit inside EBDA too, which would suck for servers with RAID, LVM, and several GB E drivers along with standard drivers and filesystems... it would be impossible to implement...
You betcha! I fought for the better part of a week to get vinum compiled in. Succeeded. 600G Raid now read/write at 60Meg/second sustained, with 100% redundancy! Then I needed netgraph. Then after doing netgraph, I found out I DIDN'T need it.

Modules woulda made it a lot easier! But the line in the kernel config that says "no_modules=not_yet" or somesuch give me hope that modules will appear soon. Meanwhile, I'm happy to live with lumpy software. Since the machine will live on the Net, I take a short solace in the fact that no 64-bit rootkits are floating around yet...

Kind of like the promised Xeon-64. Have a read...

(from slashdot...)

Now comes the shocker: Intel boss Craig Barrett today anounced that Xeon-class 64-bit server CPUs codenamed Nocona will be coming out the second half of 2004. It isn't clear whether they will support AMD's Opteron AMD64 extensions. Barrett is quoted saying, 'There will be one operating system that will support all (64-bit) extended systems.' Maybe 64-bit computing is right around the corner after all, and we may even see compatible instruction sets from Intel and AMD! And does this mean that Intel will be dumping Itanium, which never caught on as expected in the server market, and forget the billions spent on developing it?"


Quote:
I have to look into this a bit more, but it has to be a temp solution...

The CPU you are thinking of is probably the ia32-e, it does not implement any of the per page permissions, so i consider the ia32-e a second rate CPU...

Actually rereading Theos mail makes me realize that it will not only not implement any 64-bit permissions, it will not implement any 32bit permissions either... WIDE OPEN...

Hopefully they are working on that though... Theos cpu was pre-production so maybe some of it will be implemented in the finished work, time will tell... [/b]
Sir William of Bluescreen would like that chip! At any rate, Itanium is dead, total sales of 400k units overall. Not good. Xeon is dying of old age. The "pentium-4/64" or ia32-e is dead meat, too. Nobody wants a chip with no software!
shupienis is offline   Reply With Quote
Old 03-01-04, 09:30 PM   #16
SnapIT
Registered User
 
Join Date: Jun 2003
Posts: 154
Default

Quote:
Originally posted by J.F.
Intel is planning to eventually release an AMD64 compatible chip based on both Xeon and Prescott cores later this year. You can get the manuals now off Intel's site. Intel calls it ia-32e and it implements all the AMD64 instruction and architecture changes other than the No-Execute bit (which they mark as reserved, so maybe it'll still make it into the final release).

Reading through the Intel docs is rather funny. First, they make it seem like this was all their idea and that it's just a coincidence that it happens to be compatible with AMD64. You won't find an acknowledgement of AMD anywhere in the manual. Second, they try very hard not to scare away their Itanium customers. ia-32e (AMD64) is NOT a 64 bit processor, rather, it's just an extension to 64 bit addresses. However, since the addresses are 64 bits long, the registers need to be 64 bits long too. And since the addresses are 64 bits long, you need 64 bit operations to do 64 bit pointer operations. In no way are you to believe that makes it a 64 bit processor competing with Itanium.

Linux went with the symbol x86-64 because Linus preferred that to AMD64. BSD went with AMD and used AMD64. Microsoft also went with AMD64 after Intel swore they'd NEVER make an AMD64 compatible chip. So MS is in the peculiar position of having 64 bit Windows software compiling with the AMD64 symbol which will run on Intel chips.

As far as load modules go, this is the closest I could find on the FreeBSD AMD64 mailing list -



Hope it helps answer your question. If you need more info, I suggest emailing Peter.
Well, hopefully intel will realize their mistake and implement it, without it, the cpu in itself needs a bugfix, can you imagine the overhead for such a bugfix in sw in a separately loaded part of nvram? every single instruction would have to pass through... or just give it up and realize that you have a wide open system no matter what you do...

Regarding the post from Peter, i find it rather strange to change the path so soon after a closer integration goal on the other branches, it makes no sense to me, but i will look into it closer and repost what i find...

Thanx for the info....

//Patrick
SnapIT is offline   Reply With Quote
Old 03-01-04, 09:47 PM   #17
SnapIT
Registered User
 
Join Date: Jun 2003
Posts: 154
Default

Quote:
Originally posted by shupienis
You betcha! I fought for the better part of a week to get vinum compiled in. Succeeded. 600G Raid now read/write at 60Meg/second sustained, with 100% redundancy! Then I needed netgraph. Then after doing netgraph, I found out I DIDN'T need it.

Modules woulda made it a lot easier! But the line in the kernel config that says "no_modules=not_yet" or somesuch give me hope that modules will appear soon. Meanwhile, I'm happy to live with lumpy software. Since the machine will live on the Net, I take a short solace in the fact that no 64-bit rootkits are floating around yet...

Kind of like the promised Xeon-64. Have a read...

(from slashdot...)

Now comes the shocker: Intel boss Craig Barrett today anounced that Xeon-class 64-bit server CPUs codenamed Nocona will be coming out the second half of 2004. It isn't clear whether they will support AMD's Opteron AMD64 extensions. Barrett is quoted saying, 'There will be one operating system that will support all (64-bit) extended systems.' Maybe 64-bit computing is right around the corner after all, and we may even see compatible instruction sets from Intel and AMD! And does this mean that Intel will be dumping Itanium, which never caught on as expected in the server market, and forget the billions spent on developing it?"




Sir William of Bluescreen would like that chip! At any rate, Itanium is dead, total sales of 400k units overall. Not good. Xeon is dying of old age. The "pentium-4/64" or ia32-e is dead meat, too. Nobody wants a chip with no software!
The new xeon is basically ia32-e with a larger cache as i see it, i have faith in itanium II for larger systems, like SGI CC-NUMA systems, but for smaller servers i do not see the IA-64 as an alternative to AM-64 the ia32-e is somewhat a bastard child of intels where they are trying to emulate AMD (sucks to be intel these days) without implementing the extra bit for security...

The new XEON will be per byte compatible with AM-64 and so will the rest of the ia32-e cpu's, but if they do not include per page permissions, it won't last a week on the pro market...

Itanium was more of a pre production chip to set a standard to build on...
SnapIT is offline   Reply With Quote
Old 03-01-04, 09:52 PM   #18
J.F.
GeForce FX5600
 
Join Date: Dec 2003
Location: Arizona
Posts: 35
Send a message via AIM to J.F.
Default

Quote:
Originally posted by shupienis
Here's an interesting thought/question... OS-X for the Mac G5. The G5 is a 64-bit extension to a 32-bit architecture, just like the current AMD64 and the proposed future Intel Xeon-64. OS-X is a BSD kernel. What's the 64-bit driver status there?

Warmest regards!
// Joe
G5 is not an extension to the 32 bit architecture. You forgot that the PowerPC architecture was just a stripped down version of the POWER architecture, which was 64 bit originally. The PowerPC has ALWAYS had 64 bit instructions and architecture, but in the 32 bit processors, the 64 bit opcodes generate an exception to allow them to be emulated. Motorola's first CPUs were the 601, 603, 604, and 620. The 620 was a 64 bit PPC, while the others were 32 bit. Motorola never bothered to improve the 620, so IBM went back to the latest POWER CPU to make the G5.

Mac OSX 10.3 allows you to freely use 32 or 64 bit operations however you like. However, it restricts you to 32 bit addresses by setting a bit that makes the CPU truncate all pointers to 32 bits. The kernel then converts the 32 bit address into an address in the the 8GB they currently support. All that is immaterial though. Although Apple's drivers support at least 8 GBytes, they are NOT BSD drivers! Apple didn't care for the BSD driver model and tossed it out. They used a model based on the Next Mach-O kernel drivers. So OSX drivers cannot be used with other BSDs, even though OSX is mostly BSD.
J.F. is offline   Reply With Quote
Old 03-01-04, 10:01 PM   #19
shupienis
Registered User
 
Join Date: Mar 2004
Location: Pittsburgh
Posts: 10
Default

Quote:
Originally posted by J.F.
G5 is not an extension to the 32 bit architecture. You forgot that the PowerPC architecture was just a stripped down version of the POWER architecture, which was 64 bit originally. The PowerPC has ALWAYS had 64 bit instructions and architecture, but in the 32 bit processors, the 64 bit opcodes generate an exception to allow them to be emulated.


Thank you. I stand corrected.

Quote:
Apple didn't care for the BSD driver model and tossed it out. They used a model based on the Next Mach-O kernel drivers. So OSX drivers cannot be used with other BSDs, even though OSX is mostly BSD.
Now that is really interesting, and pertinent to my own selfish little corner of the universe, because -- as I understand it -- the FreeBSD AMD64 kernel is also a Mach-based kernel. (How fitting that I sing weekly (weakly?) across the street from the CMU Software Engineering Institute here in Pittsburgh!)

This discussion is getting interesting, now!

... // Joe
shupienis is offline   Reply With Quote
Old 03-01-04, 10:04 PM   #20
SnapIT
Registered User
 
Join Date: Jun 2003
Posts: 154
Default

Quote:
Originally posted by J.F.
G5 is not an extension to the 32 bit architecture. You forgot that the PowerPC architecture was just a stripped down version of the POWER architecture, which was 64 bit originally. The PowerPC has ALWAYS had 64 bit instructions and architecture, but in the 32 bit processors, the 64 bit opcodes generate an exception to allow them to be emulated. Motorola's first CPUs were the 601, 603, 604, and 620. The 620 was a 64 bit PPC, while the others were 32 bit. Motorola never bothered to improve the 620, so IBM went back to the latest POWER CPU to make the G5.

Mac OSX 10.3 allows you to freely use 32 or 64 bit operations however you like. However, it restricts you to 32 bit addresses by setting a bit that makes the CPU truncate all pointers to 32 bits. The kernel then converts the 32 bit address into an address in the the 8GB they currently support. All that is immaterial though. Although Apple's drivers support at least 8 GBytes, they are NOT BSD drivers! Apple didn't care for the BSD driver model and tossed it out. They used a model based on the Next Mach-O kernel drivers. So OSX drivers cannot be used with other BSDs, even though OSX is mostly BSD.
Yup, the cpu in itself is 64, so was G4 in essence but the programmers are still stuck on old code and implements, so interpreted code is what it runs today...

I just realized that the prescott does not support the NX bit at all, not in any implementation, i cannot figure out why, it could just be available, all code that i know of would run fine... If not, AMD are true wizards...

I assume JAVA could write write to a processes stack space, but other than that... well... and it would be simpler to do the workaround...

Can anyone explain how NX would present a compatibility issue?
SnapIT is offline   Reply With Quote

Old 03-01-04, 10:10 PM   #21
J.F.
GeForce FX5600
 
Join Date: Dec 2003
Location: Arizona
Posts: 35
Send a message via AIM to J.F.
Default

Quote:
Originally posted by SnapIT
Well, hopefully intel will realize their mistake and implement it, without it, the cpu in itself needs a bugfix, can you imagine the overhead for such a bugfix in sw in a separately loaded part of nvram? every single instruction would have to pass through... or just give it up and realize that you have a wide open system no matter what you do...
Actually, a sw fix is pretty easy with only a small performance hit. When a page fault occurs, set the MMU tables and do an access to force the TLBs to load the entry, then go back and use the test registers to invalidate the instruction TLB for that page. This leaves the data TLB with a valid translation, but any instruction accesses will cause another page fault. In the second page fault, simulate the no-execute. This works on x86 CPUs allowing access to the TLB through the test registers AND uses separate TLBs for data and code access. This means you can simulate NX with a little extra code in the page fault handler of Pentium and newer chips, but not on the 486 or older. The 486 allows the access of the TLB via the test registers, but only had one TLB to handle both data and code.
J.F. is offline   Reply With Quote
Old 03-01-04, 10:22 PM   #22
J.F.
GeForce FX5600
 
Join Date: Dec 2003
Location: Arizona
Posts: 35
Send a message via AIM to J.F.
Default

Quote:
Originally posted by shupienis

Now that is really interesting, and pertinent to my own selfish little corner of the universe, because -- as I understand it -- the FreeBSD AMD64 kernel is also a Mach-based kernel. (How fitting that I sing weekly (weakly?) across the street from the CMU Software Engineering Institute here in Pittsburgh!)

This discussion is getting interesting, now!

... // Joe
Well, you could always check out the Darwin page.

http://developer.apple.com/darwin/

That is the kernel and drivers for OSX. The latest code equivalent to 10.3 is freely available. What is interesting is that Apple supports Darwin on x86 machines. It's not got as many drivers as the PowerPC version, but there are folks running Darwin and X11 on their PCs. I don't think they've modified the x86 version to handle AMD64 though.
J.F. is offline   Reply With Quote
Old 03-01-04, 10:50 PM   #23
SnapIT
Registered User
 
Join Date: Jun 2003
Posts: 154
Default

Quote:
Originally posted by J.F.
Actually, a sw fix is pretty easy with only a small performance hit. When a page fault occurs, set the MMU tables and do an access to force the TLBs to load the entry, then go back and use the test registers to invalidate the instruction TLB for that page. This leaves the data TLB with a valid translation, but any instruction accesses will cause another page fault. In the second page fault, simulate the no-execute. This works on x86 CPUs allowing access to the TLB through the test registers AND uses separate TLBs for data and code access. This means you can simulate NX with a little extra code in the page fault handler of Pentium and newer chips, but not on the 486 or older. The 486 allows the access of the TLB via the test registers, but only had one TLB to handle both data and code.
Actually, no, it does not work like that as the software can only control its own instructions if NX is only in software, malicious code can be run at any overload, your program will crash and the code can run, i can see some heavy problems coming with that...

There is no bit to set NX if it is not implemented so...

Now, for the ia32 implementation this is no biggie as you can easily simulate NX, but that will not work on AM-64, so there IS a very real problem with this...
SnapIT is offline   Reply With Quote
Old 03-01-04, 10:54 PM   #24
SnapIT
Registered User
 
Join Date: Jun 2003
Posts: 154
Default

Quote:
Originally posted by shupienis
Thank you. I stand corrected.



Now that is really interesting, and pertinent to my own selfish little corner of the universe, because -- as I understand it -- the FreeBSD AMD64 kernel is also a Mach-based kernel. (How fitting that I sing weekly (weakly?) across the street from the CMU Software Engineering Institute here in Pittsburgh!)

This discussion is getting interesting, now!

... // Joe
Apple took the Mach arch and created something that is basically a 64 bit kernel with 32 bit drivers and a layer to interpret external syscalls from 32-64...

A PPC native 64 kernel COULD be extremely fast on a G5, in time we will see that happen though, Apple are doing what MS did with win95 16-32...
SnapIT is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


Similar Threads
Thread Thread Starter Forum Replies Last Post
Reasons Why You Should Not Use FreeBSD News Archived News Items 0 06-02-12 09:40 AM
Why Should You Use FreeBSD? Here's Some Reasons News Archived News Items 0 05-31-12 01:10 PM
nvidia-driver-295.49 is highly unstable on FreeBSD 9.0 with 9400GT card yurivict NVIDIA FreeBSD 0 05-28-12 12:14 PM
FreeBSD 9 Release with Nvidia 550 Ti configuration issues goga NVIDIA FreeBSD 0 05-23-12 08:34 AM
NVIDIA drivers 302.11 for Linux, FreeBSD and Solaris News Archived News Items 0 05-19-12 11:20 AM

All times are GMT -5. The time now is 06:23 PM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.