fc1_x86_64 preview on tyan thunder k8w (S2885ANRF REV .03)

[Rob Myers]

hello-

thanks for getting fedora working on x86_64!

i've tried to search linux-kernel archives, archives at www.x86-64.org,
and bugzilla at redhat.com, but i haven't found all the answers i'm
looking for.  is there a faq anywhere for linux on x86_64 or even for
fedora on x86_64?

my system is running fedora core 1 x86_64 preview updated to kernel
2.4.22-1.2129.nptlsmp on dual opteron 248 2.2GHz tyan thunder k8w with
4gb of ram.  acpi=off is passed to the kernel as a boot parameter or
else it hangs with dma errors during or after boot.

first, i've got 4gb of ram in the machine, but cat /proc/meminfo only
reports 3.5gb free:
        total:    used:    free:  shared: buffers:  cached:
Mem:  3539730432 91926528 3447803904        0 24104960 29126656
Swap: 4186656768        0 4186656768

is this a bug or am i missing something?  i also tried passing mem=4G
with no success

second, AMD-8111 IDE has dma timeouts if acpi is enabled.  is this a
known issue?

third, just to report my experience: (i think these are known issues)

- the onboard broadcom 5703 based gigabit does not work properly with
tg3, but broadcom 5701 based 3Com 3C996B-T does work properly with tg3.
- the onboard sil SATA controller does not work
- kernel-smp-2.6.0-0.test11.1.100.x86_64.rpm from
http://people.redhat.com/arjanv/2.5/RPMS.kernel does not boot, just
oopses to the console.

thanks for any help, info or pointers.

rob.

ps- dmesg attached in case that will provide any useful info.

[Mark Lane]

On Wed, 2003-12-10 at 09:18, Rob Myers wrote:
>  hello-
>  
>  thanks for getting fedora working on x86_64!
>  
>  i've tried to search linux-kernel archives, archives at www.x86-64.org,
>  and bugzilla at redhat.com, but i haven't found all the answers i'm
>  looking for.  is there a faq anywhere for linux on x86_64 or even for
>  fedora on x86_64?
>  
>  my system is running fedora core 1 x86_64 preview updated to kernel
>  2.4.22-1.2129.nptlsmp on dual opteron 248 2.2GHz tyan thunder k8w with
>  4gb of ram.  acpi=off is passed to the kernel as a boot parameter or
>  else it hangs with dma errors during or after boot.
>  
>  first, i've got 4gb of ram in the machine, but cat /proc/meminfo only
>  reports 3.5gb free:
>          total:    used:    free:  shared: buffers:  cached:
>  Mem:  3539730432 91926528 3447803904        0 24104960 29126656
>  Swap: 4186656768        0 4186656768
>  
>  is this a bug or am i missing something?  i also tried passing mem=4G
>  with no success
>   
The PCI bus is Memory Mapped at just below the 4GB mark. That's why you
can use the last half GB.

>  second, AMD-8111 IDE has dma timeouts if acpi is enabled.  is this a
>  known issue?
>   
I believe we tend to shut off acpi because it usually hasn't worked with
our dual opteron systems.

>  third, just to report my experience: (i think these are known
> issues)
>  
>  - the onboard broadcom 5703 based gigabit does not work properly with
>  tg3, but broadcom 5701 based 3Com 3C996B-T does work properly with tg3. 
We had this working but I am not sure what driver we used.

>  - the onboard sil SATA controller does not work 
Yes this doesn't work because no drivers existed. 2.6.0-test11 has a
patch that will get this working.

>  - kernel-smp-2.6.0-0.test11.1.100.x86_64.rpm from
>  http://people.redhat.com/arjanv/2.5/RPMS.kernel does not boot, just
>  oopses to the console.
>   
I haven't had any luck with Arjan's Kernels on our x86_64 systems. We
just compiled our own.

regards,
-- 
Mark Lane, CET	mailto:[e-mail] 
Hard Data Ltd.	http://www.harddata.com 
T: 01-780-456-9771 	F: 01-780-456-9772
11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3
--> Ask me about our Excellent 1U Systems! <--

[Rob Myers]

On Wed, 2003-12-10 at 11:33, Mark Lane wrote:
>  On Wed, 2003-12-10 at 09:18, Rob Myers wrote:
>  > first, i've got 4gb of ram in the machine, but cat /proc/meminfo only
>  > reports 3.5gb free:
>  >         total:    used:    free:  shared: buffers:  cached:
>  > Mem:  3539730432 91926528 3447803904        0 24104960 29126656
>  > Swap: 4186656768        0 4186656768
>  > 
>  > is this a bug or am i missing something?  i also tried passing mem=4G
>  > with no success
>  > 
>  
>  The PCI bus is Memory Mapped at just below the 4GB mark. That's why you
>  can use the last half GB. 
i'm not sure i understand.  i _can_ use the last half GB?  but the
kernel doesnt report it as available?  could you please explain this
further or point me towards some other documentation?  if i put 8gb of
ram in this machine what will the kernel report as available?

>  I haven't had any luck with Arjan's Kernels on our x86_64
> systems. We
>  just compiled our own. 
i haven't had any success booting my own 2.6 either, but i'll try again!

thanks

rob.

[Rob Myers]

On Wed, 2003-12-10 at 12:26, Rob Myers wrote:
>  On Wed, 2003-12-10 at 11:33, Mark Lane wrote:
>  > The PCI bus is Memory Mapped at just below the 4GB mark. That's why you
>  > can use the last half GB.
>  
>  i'm not sure i understand.  i _can_ use the last half GB?  but the
>  kernel doesnt report it as available?  could you please explain this
>  further or point me towards some other documentation?  if i put 8gb of
>  ram in this machine what will the kernel report as available? 
to respond to myself, i tested 8gb of ram and the kernel
(2.4.22-1.2129.nptlsmp) only reports 3.5gb.

all pointers/tips/insight/solutions welcome!

rob.

[Ron Kuris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rob Myers wrote:

|
| to respond to myself, i tested 8gb of ram and the kernel
| (2.4.22-1.2129.nptlsmp) only reports 3.5gb.

Can you run '/sbin/grub' and then 'displaymem' and provide the output
here?

Ron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE/122/VkC/44kdyuYRAk6uAKDuf/J2YMLkny7sWZQqV9vpP5MxHwCcCXZx
> MMDzvKGhZeQWuaa2QFrldOM=
> =K+5e
> -----END PGP SIGNATURE-----

[Rob Myers]

On Wed, 2003-12-10 at 14:02, Ron Kuris wrote:
>  |
>  | to respond to myself, i tested 8gb of ram and the kernel
>  | (2.4.22-1.2129.nptlsmp) only reports 3.5gb.
>  
>  Can you run '/sbin/grub' and then 'displaymem' and provide the output
> here? 
# /sbin/grub
Probing devices to guess BIOS drives. This may take a long time.


    GRUB  version 0.93  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the
possible
   completions of a device/filename.]
grub> displaymem
displaymem
 EISA Memory BIOS Interface is present
 Address Map BIOS Interface is present
 Lower memory: 640K, Upper memory (to first chipset hole): 3072K
 [Address Range Descriptor entries immediately follow (values are
64-bit)]
   Usable RAM:  Base Address:  0x0 X 4GB + 0x0,
      Length:   0x0 X 4GB + 0xa0000 bytes
   Reserved:  Base Address:  0x0 X 4GB + 0xa0000,
      Length:   0x0 X 4GB + 0x60000 bytes
   Usable RAM:  Base Address:  0x0 X 4GB + 0x100000,
      Length:   0x0 X 4GB + 0x300000 bytes
grub>

care to interpret the meaning of this output for me? :)

thanks the help!

rob.

[Ron Kuris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rob Myers wrote:

|> | to respond to myself, i tested 8gb of ram and the kernel |
|> (2.4.22-1.2129.nptlsmp) only reports 3.5gb.
|
| Lower memory: 640K, Upper memory (to first chipset hole): 3072K
| [Address Range Descriptor entries immediately follow (values are
| 64-bit)] Usable RAM:  Base Address:  0x0 X 4GB + 0x0, Length:   0x0 X
| 4GB + 0xa0000 bytes Reserved:  Base Address:  0x0 X 4GB + 0xa0000,
| Length:   0x0 X 4GB + 0x60000 bytes Usable RAM:  Base Address:  0x0 X
| 4GB + 0x100000, Length:   0x0 X 4GB + 0x300000 bytes

This output is normal.  I was suspecting that perhaps you had something
else reserved in your first 4GB, but grub doesn't detect that.

I don't know enough about how PAE works on the AMD as compared to Intel,
but for some reason PAE isn't working right.  When the system boots,
check out the memory map in your /var/log/messages file.  It should look
something like this (this machine has 6GB and is an Intel, not AMD):

Nov 18 12:34:52 cleo kernel: BIOS-provided physical RAM map:
Nov 18 12:34:52 cleo kernel:  BIOS-e820: 0000000000000000 -
00000000000a0000 (usable)
Nov 18 12:34:52 cleo kernel:  BIOS-e820: 0000000000100000 -
00000000efff0000 (usable)
Nov 18 12:34:52 cleo kernel:  BIOS-e820: 00000000efff0000 -
00000000efffec00 (ACPI data)
Nov 18 12:34:52 cleo kernel:  BIOS-e820: 00000000efffec00 -
00000000effff000 (reserved)
Nov 18 12:34:52 cleo kernel:  BIOS-e820: 00000000fec00000 -
00000000fec10000 (reserved)
Nov 18 12:34:52 cleo kernel:  BIOS-e820: 00000000fee00000 -
00000000fee10000 (reserved)
Nov 18 12:34:52 cleo kernel:  BIOS-e820: 00000000fff80000 -
0000000100000000 (reserved)
Nov 18 12:34:52 cleo kernel:  BIOS-e820: 0000000100000000 -
0000000180000000 (usable)
Nov 18 12:34:52 cleo kernel: 5248MB HIGHMEM available.
Nov 18 12:34:52 cleo kernel: 896MB LOWMEM available.
Nov 18 12:34:52 cleo kernel: found SMP MP-table at 000fe710
Nov 18 12:34:52 cleo kernel: hm, page 000fe000 reserved twice.
Nov 18 12:34:52 cleo kernel: hm, page 000ff000 reserved twice.
Nov 18 12:34:52 cleo syslog: klogd startup succeeded
Nov 18 12:34:52 cleo kernel: hm, page 000f0000 reserved twice.
Nov 18 12:34:52 cleo kernel: On node 0 totalpages: 1572864
Nov 18 12:34:52 cleo kernel: zone(0): 4096 pages.
Nov 18 12:34:52 cleo kernel: zone(1): 225280 pages.
Nov 18 12:34:52 cleo kernel: zone(2): 1343488 pages.

Ron
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE/14DOVkC/44kdyuYRAs7MAJ9s9ElLfXHBBrvUd08BeGHnWi01ugCfVDLS
> 8cwxReaJ5u83K3zwTg77zzQ=
> =zsm9
> -----END PGP SIGNATURE-----

[Rob Myers]

On Wed, 2003-12-10 at 13:06, Rob Myers wrote:
>  to respond to myself, i tested 8gb of ram and the kernel
>  (2.4.22-1.2129.nptlsmp) only reports 3.5gb.
>   
well that's because i had the mem=4gb kernel param in there still. 
without that, it shows 7.5gb free.  i am sorry for the misinformation
earlier.

i still don't understand where the extra half gigabyte of ram disappears
to, however.

i am still unable to get 2.6.0-test11-x86_64-3 to boot on this system,
tho it is likely due to my unfamiliarity with 2.6 and my unfamiliarity
with the architecture.

thanks for everyone's help today!

rob.

[Thomas Dodd]

Rob Myers wrote:
>  On Wed, 2003-12-10 at 13:06, Rob Myers wrote:
>  
> >to respond to myself, i tested 8gb of ram and the kernel
> >(2.4.22-1.2129.nptlsmp) only reports 3.5gb.
> >
>  well that's because i had the mem=4gb kernel param in there still. 
>  without that, it shows 7.5gb free.  i am sorry for the misinformation
>  earlier.
>  
>  i still don't understand where the extra half gigabyte of ram disappears
>  to, however. 
It was sort of explained before by Mark. What was ment is you _cannot_ 
use the last .5G because it's mapped to PCI.

There may be some trick to move that though. I remember this was a 
problem for 32bit too. PCI+kernel took the last 1GB on a 4GB box, so 
processes only got 3GB. There were sopme hack to get 3.5GB on those, so 
it might be posible to get more on 64bit systems. Maybe only loose 0.25GB?

	-Thomas

[Alan Cox]

On Thu, Dec 11, 2003 at 04:11:26PM -0600, Thomas Dodd wrote:
>  It was sort of explained before by Mark. What was ment is you
> _cannot_ 
>  use the last .5G because it's mapped to PCI. 
Thats the physical memory map. Because PCI is 32bit for some cards you 
end up with a PCI hole (remember the ISA hole.. now we have two 8))

So its

  0-639K		RAM
  640K-1Mb		ISA + ROM window
  1Mb-3.5Gb		RAM
  3.5Gb-4Gb		PCI plus ROM plus APIC etc
  4Gb->...		RAM
  

>  There may be some trick to move that though. I remember this was a 
>  problem for 32bit too. PCI+kernel took the last 1GB on a 4GB box, so 
>  processes only got 3GB. There were sopme hack to get 3.5GB on those, so 
>  it might be posible to get more on 64bit systems. Maybe only loose 0.25GB? 
Thats different. You end up needing some mappings for kernel and user
space to be efficient when dealing with user mappings. Whether you can
get your .5Gb back depends if the chipset can remap it higher up in memory
so that the 3.5-4Gb RAM masked by PCI is remapped at the top of memory.

Alan

[Thomas Dodd]

Alan Cox wrote:
>  On Thu, Dec 11, 2003 at 04:11:26PM -0600, Thomas Dodd wrote:
>  
> >It was sort of explained before by Mark. What was ment is you _cannot_ 
> >use the last .5G because it's mapped to PCI.
>  
>  
>  Thats the physical memory map. Because PCI is 32bit for some cards you 
>  end up with a PCI hole (remember the ISA hole.. now we have two 8)) 
That makes sense. Thanks Alan.

>  So its
>  
>    0-639K		RAM
>    640K-1Mb		ISA + ROM window 
Is the and ISA bus on any x86-64 board?
Is it possible?

I don't think you can even find a SocketA board with ISA slots.
I have a ISA card I cannot replace right now that's keept me on a SlotA 
  board and a lowly 800MHz Thunderbird Athlon.

> >There may be some trick to move that though. I remember this was a
>
> >problem for 32bit too. PCI+kernel took the last 1GB on a 4GB box, so 
> >processes only got 3GB. There were sopme hack to get 3.5GB on those, so 
> >it might be posible to get more on 64bit systems. Maybe only loose 0.25GB?
>  
>  
>  Thats different. You end up needing some mappings for kernel and user
>  space to be efficient when dealing with user mappings. Whether you can
>  get your .5Gb back depends if the chipset can remap it higher up in memory
>  so that the 3.5-4Gb RAM masked by PCI is remapped at the top of memory. 
Know which ones, if any, currently can? AMD, Nvidia, or VIA?
Why would they release a chip that couldn't?

	-Thomas

[Alan Cox]

>  >Thats different. You end up needing some mappings for kernel and
> user
>  >space to be efficient when dealing with user mappings. Whether you can
>  >get your .5Gb back depends if the chipset can remap it higher up in memory
>  >so that the 3.5-4Gb RAM masked by PCI is remapped at the top of memory.
>  
>  Know which ones, if any, currently can? AMD, Nvidia, or VIA? 
I don't

>  Why would they release a chip that couldn't? 
I've no idea how complex it is to do that so I can't guess

[Joshua Baker-LePain]

On Thu, 11 Dec 2003 at 4:56pm, Thomas Dodd wrote

>  Alan Cox wrote: 
>  > Thats different. You end up needing some mappings for kernel and
> user
>  > space to be efficient when dealing with user mappings. Whether you can
>  > get your .5Gb back depends if the chipset can remap it higher up in memory
>  > so that the 3.5-4Gb RAM masked by PCI is remapped at the top of memory.
>  
>  Know which ones, if any, currently can? AMD, Nvidia, or VIA?
>  Why would they release a chip that couldn't? 
In my (limited) experience, I've only "lost" significant chunks of memory 
on Tyan boards.  Here are the results of 'free' on two systems with 4GB of 
RAM installed:

             total       used       free     shared    buffers     cached
Mem:       3688032    3258792     429240          0     105380    2519000
-/+ buffers/cache:     634412    3053620

             total       used       free     shared    buffers     cached
Mem:       4012172    3476620     535552          0      67296    2975540
-/+ buffers/cache:     433784    3578388

The first system is dual Athlon MPs on a Tyan S2466.  The second is
dual Xeons on a Supermicro P4DPE.  For good measure, here's free from a 
dual Opteron system with 8GB installed:

             total       used       free     shared    buffers     cached
Mem:       8070688     444488    7626200          0      99488     148820
-/+ buffers/cache:     196180    7874508

That's the Arima/Rioworks HDAMA motherboard.  Given my past experiences 
with Tyan and AMD chipsets (read: S2460 *shudder*), I specifically 
requested that my vendor *not* use the Tyan MB in my Opteron systems.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

[Thomas Dodd]

Joshua Baker-LePain wrote:
>  On Thu, 11 Dec 2003 at 4:56pm, Thomas Dodd wrote
> >Know which ones, if any, currently can? AMD, Nvidia, or VIA?
> >Why would they release a chip that couldn't?
>  
>  
>  In my (limited) experience, I've only "lost" significant chunks of memory 
>  on Tyan boards.  Here are the results of 'free' on two systems with 4GB of 
>  RAM installed:
>  
>               total       used       free     shared    buffers     cached
>  Mem:       3688032    3258792     429240          0     105380    2519000
>  -/+ buffers/cache:     634412    3053620
>  
>               total       used       free     shared    buffers     cached
>  Mem:       4012172    3476620     535552          0      67296    2975540
>  -/+ buffers/cache:     433784    3578388
>  
>  The first system is dual Athlon MPs on a Tyan S2466.  The second is
>  dual Xeons on a Supermicro P4DPE.  For good measure, here's free from a  
Which chipsets are those? Not familiar with the individual boards, 
especially not ones for Intel CPUs.

>  dual Opteron system with 8GB installed:
>  
>               total       used       free     shared    buffers     cached
>  Mem:       8070688     444488    7626200          0      99488     148820
>  -/+ buffers/cache:     196180    7874508
>  
>  That's the Arima/Rioworks HDAMA motherboard.  Given my past experiences 
>  with Tyan and AMD chipsets (read: S2460 *shudder*), I specifically 
>  requested that my vendor *not* use the Tyan MB in my Opteron systems. 
So what chipset does that board use? I though all the early K8 boards 
used AMD chipsets. Anyone no more about the other K8 boards?
Especially workstation boards (dual opteron with AGP).

	-Thomas

[Joshua Baker-LePain]

On Fri, 12 Dec 2003 at 9:11am, Thomas Dodd wrote

>  >              total       used       free     shared    buffers  
>   cached
>  > Mem:       3688032    3258792     429240          0     105380    2519000
>  > -/+ buffers/cache:     634412    3053620
>  > 
>  >              total       used       free     shared    buffers     cached
>  > Mem:       4012172    3476620     535552          0      67296    2975540
>  > -/+ buffers/cache:     433784    3578388
>  > 
>  > The first system is dual Athlon MPs on a Tyan S2466.  The second is
>  > dual Xeons on a Supermicro P4DPE.  For good measure, here's free from a 
>  
>  Which chipsets are those? Not familiar with the individual boards, 
>  especially not ones for Intel CPUs. 
The Tyan uses the AMD 760-MPX, and the Supermicro uses the Intel E7500.

>  > dual Opteron system with 8GB installed:
>  > 
>  >              total       used       free     shared    buffers     cached
>  > Mem:       8070688     444488    7626200          0      99488     148820
>  > -/+ buffers/cache:     196180    7874508
>  > 
>  > That's the Arima/Rioworks HDAMA motherboard.  Given my past experiences 
>  > with Tyan and AMD chipsets (read: S2460 *shudder*), I specifically 
>  > requested that my vendor *not* use the Tyan MB in my Opteron systems.
>  
>  So what chipset does that board use? I though all the early K8 boards 
>  used AMD chipsets. Anyone no more about the other K8 boards?
>  Especially workstation boards (dual opteron with AGP). 
Yes, it uses the AMD chipset.  They also have the HDAMB, which is a 
workstation board:

http://www.rioworks.com/HDAMB.htm

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

[Jesse Keating]

On Wednesday 10 December 2003 10:06, Rob Myers wrote:
>  to respond to myself, i tested 8gb of ram and the kernel
>  (2.4.22-1.2129.nptlsmp) only reports 3.5gb.
>
>  all pointers/tips/insight/solutions welcome! 
Thats not a "bigmem" kernel.  I don't think that kernel has PAE enabled, 
so you're limited to "4gigs" of ram.

-- 
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team      (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam           (www.mondorescue.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating

[Jesse Keating]

On Wednesday 10 December 2003 15:57, Jesse Keating wrote:
>  Thats not a "bigmem" kernel.  I don't think that kernel
> has PAE
>  enabled, so you're limited to "4gigs" of ram. 
Whoops, I take this back. I see by your other email that this wasn't the 
case.  Does x86_64 even need PAE to access more than 4 gigs of ram?

-- 
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team      (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam           (www.mondorescue.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating

[Robert G. (Doc) Savage]

On Wednesday December 10, 2003 Jesse Keating wrote:
>  On Wednesday 10 December 2003 15:57, Jesse Keating wrote:
> > Thats not a "bigmem" kernel.  I don't think that kernel has PAE
> > enabled, so you're limited to "4gigs" of ram.
>
>  Whoops, I take this back. I see by your other email that this wasn't the
>   case.  Does x86_64 even need PAE to access more than 4 gigs of ram? 
Nope. Flat addressing up to 2^64. (Carl Sagen, we miss ya!) Motherboard
makers might not lay down all 64 traces though.

--Doc Savage
  Fairview Heights, IL

[Bryan O'Sullivan]

On Wed, 2003-12-10 at 16:21, dsavage(a)peaknet.net wrote:

>  Nope. Flat addressing up to 2^64. 
2^47, actually.  The upper 17 bits of a virtual address are required to
be all 1 or all 0, or else the CPU raises a GPF.  And there are still
segments present, even in long mode, but they behave very weirdly.

	<b

[Justin M. Forbes]

On Wed, Dec 10, 2003 at 12:26:20PM -0500, Rob Myers wrote:
>  
>  i haven't had any success booting my own 2.6 either, but i'll try again! 
look for the 2.6 patches at x86-64.org, those include the pieces which have
not been merged to mainline yet.

Justin

[Justin M. Forbes]

On Wed, Dec 10, 2003 at 11:18:50AM -0500, Rob Myers wrote:
>  
>  second, AMD-8111 IDE has dma timeouts if acpi is enabled.  is this a
>  known issue?
>   
ACPI is a known issue with most NF3 systems, and it seems some of the AMD
chipset based.  I have been talking to AMD on this, and they specifically
mention Tyan as having issues which were fixed with a bios upgrade.  I will
see if I can get more info on it.

>  - the onboard broadcom 5703 based gigabit does not work properly
> with
>  tg3, but broadcom 5701 based 3Com 3C996B-T does work properly with tg3. 
Not sure on
this, will check to see what driver if any supports this nic.

>  - the onboard sil SATA controller does not work 
This is a known
issue, and being addressed, but might not be ready in time
for FC1.  

>  - kernel-smp-2.6.0-0.test11.1.100.x86_64.rpm from
>  http://people.redhat.com/arjanv/2.5/RPMS.kernel does not boot, just
>  oopses to the console.
>   
The 2.6test kernels have some known issues with AMD64.  These are being
addressed, and active patches are available, but have not been merged with
mainline yet.  This should be fixed soon I hope. 

I will work on an FAQ and put that up tonight.  As for the memory issues, I
am not entirely sure, but you are not the first to report this.  I will
look into it as I can, but I unfortunately do not have this much memory in
any of my systems, and to buy it might end in divorce at this point :). I
am working with AMD to try to get access to the developer labs, and
hopefully this will help address some of these issues.

Justin

[Rob Myers]

On Wed, 2003-12-10 at 11:35, Justin M. Forbes wrote:
>  On Wed, Dec 10, 2003 at 11:18:50AM -0500, Rob Myers wrote:
>  > 
>  > second, AMD-8111 IDE has dma timeouts if acpi is enabled.  is this a
>  > known issue?
>  > 
>  ACPI is a known issue with most NF3 systems, and it seems some of the AMD
>  chipset based.  I have been talking to AMD on this, and they specifically
>  mention Tyan as having issues which were fixed with a bios upgrade.  I will
>  see if I can get more info on it. 
i'm running the latest bios v1.01.

>  I will work on an FAQ and put that up tonight.  As for the memory
> issues, I
>  am not entirely sure, but you are not the first to report this.  I will
>  look into it as I can, but I unfortunately do not have this much memory in
>  any of my systems, and to buy it might end in divorce at this point :). I
>  am working with AMD to try to get access to the developer labs, and
>  hopefully this will help address some of these issues. 
looking forward to the FAQ!  i'd be glad to try out any patches that
require that amount of memory to be tested.

thanks again

rob.