[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Errors after AMD64 install but not with the 32bit install



Hello everyone!

I just did another Debian Lenny AMD64 install. However, it wasn't as smooth as the other installs. This time I have three errors that I am still trying to figure out. For what it is worth, when I install the 32bit version* I do not get these errors at all and all of the hardware works as it should.

*I downloaded the 64 and 32 bit versions at the same time and I did network installs so they should have a pretty similar package versions.


Problem #1

Nov 27 23:28:31 SK kernel: [    0.004000] Aperture pointing to e820 RAM. Ignoring.
Nov 27 23:28:31 SK kernel: [    0.004000] No AGP bridge found
Nov 27 23:28:31 SK kernel: [    0.004000] Your BIOS doesn't leave a aperture memory hole
Nov 27 23:28:31 SK kernel: [    0.004000] Please enable the IOMMU option in the BIOS setup
Nov 27 23:28:31 SK kernel: [    0.004000] This costs you 64 MB of RAM
Nov 27 23:28:31 SK kernel: [    0.004000] Mapping aperture over 65536 KB of RAM @ 4000000
Nov 27 23:28:31 SK kernel: [    0.004000] PM: Registered nosave memory: 0000000004000000 - 0000000008000000
Nov 27 23:28:31 SK kernel: [    0.004000] Memory: 4056728k/4718592k available (2226k kernel code, 136100k reserved, 1079k data, 392k init)

I have found several forums that, since I have PCI-Express and no agp, they recommend disabling AGP with "iommu=noagp" in the kernel boot list in grub. However, this doesn't seem to work. I still have these messages everytime I boot up. I have found no such IOMMU options in the BIOS and google searching for my system returns very little and nothing helpful.


Problem #2

Nov 27 23:28:31 SK kernel: [    0.252015] PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 255
Nov 27 23:28:31 SK kernel: [    0.260976] PCI: BIOS Bug: MCFG area at f0000000 is not reserved in ACPI motherboard resources
Nov 27 23:28:31 SK kernel: [    0.261017] PCI: Not using MMCONFIG.

>From the google searches I did, it looks like this is harmless, but I just want to be sure. I think this is related to the first problem. Can anyone give me a bit more information?


Problem #3
$ lspci  | grep Intel
04:09.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)

$ cat /var/log/messages
[snip]
Nov 29 09:34:17 SK kernel: [  249.993244] e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Nov 29 09:34:17 SK kernel: [  249.993244] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Nov 29 09:34:19 SK kernel: [  252.475565]   Tx Queue             <0>
Nov 29 09:34:19 SK kernel: [  252.475566]   TDH                  <8>
Nov 29 09:34:19 SK kernel: [  252.475567]   TDT                  <8>
Nov 29 09:34:19 SK kernel: [  252.475568]   next_to_use          <8>
Nov 29 09:34:19 SK kernel: [  252.475569]   next_to_clean        <0>
Nov 29 09:34:19 SK kernel: [  252.475570] buffer_info[next_to_clean]
Nov 29 09:34:19 SK kernel: [  252.475570]   time_stamp           <ffffc1d7>
Nov 29 09:34:19 SK kernel: [  252.475571]   next_to_watch        <0>
Nov 29 09:34:19 SK kernel: [  252.475572]   jiffies              <ffffc43d>
Nov 29 09:34:19 SK kernel: [  252.475573]   next_to_watch.status <0>
Nov 29 09:34:21 SK kernel: [  254.481301]   Tx Queue             <0>
Nov 29 09:34:21 SK kernel: [  254.481302]   TDH                  <8>
Nov 29 09:34:21 SK kernel: [  254.481303]   TDT                  <8>
Nov 29 09:34:21 SK kernel: [  254.481304]   next_to_use          <8>
Nov 29 09:34:21 SK kernel: [  254.481305]   next_to_clean        <0>
Nov 29 09:34:21 SK kernel: [  254.481305] buffer_info[next_to_clean]
Nov 29 09:34:21 SK kernel: [  254.481306]   time_stamp           <ffffc1d7>
Nov 29 09:34:21 SK kernel: [  254.481307]   next_to_watch        <0>
Nov 29 09:34:21 SK kernel: [  254.481308]   jiffies              <ffffc631>
Nov 29 09:34:21 SK kernel: [  254.481309]   next_to_watch.status <0>
Nov 29 09:34:23 SK kernel: [  256.709472]   Tx Queue             <0>
Nov 29 09:34:23 SK kernel: [  256.709473]   TDH                  <8>
Nov 29 09:34:23 SK kernel: [  256.709474]   TDT                  <8>
Nov 29 09:34:23 SK kernel: [  256.709475]   next_to_use          <8>
Nov 29 09:34:23 SK kernel: [  256.709475]   next_to_clean        <0>
Nov 29 09:34:23 SK kernel: [  256.709476] buffer_info[next_to_clean]
Nov 29 09:34:23 SK kernel: [  256.709477]   time_stamp           <ffffc1d7>
Nov 29 09:34:23 SK kernel: [  256.709478]   next_to_watch        <0>
Nov 29 09:34:23 SK kernel: [  256.709479]   jiffies              <ffffc825>
Nov 29 09:34:23 SK kernel: [  256.709480]   next_to_watch.status <0>
Nov 29 09:34:25 SK kernel: [  258.716503]   Tx Queue             <0>
Nov 29 09:34:25 SK kernel: [  258.716504]   TDH                  <8>
Nov 29 09:34:25 SK kernel: [  258.716504]   TDT                  <8>
Nov 29 09:34:25 SK kernel: [  258.716505]   next_to_use          <8>
Nov 29 09:34:25 SK kernel: [  258.716506]   next_to_clean        <0>
Nov 29 09:34:25 SK kernel: [  258.716507] buffer_info[next_to_clean]
Nov 29 09:34:25 SK kernel: [  258.716508]   time_stamp           <ffffc1d7>
Nov 29 09:34:25 SK kernel: [  258.716508]   next_to_watch        <0>
Nov 29 09:34:25 SK kernel: [  258.716509]   jiffies              <ffffca19>
Nov 29 09:34:25 SK kernel: [  258.716510]   next_to_watch.status <0>
Nov 29 09:34:27 SK kernel: [  260.871565] NETDEV WATCHDOG: eth1: transmit timed out
Nov 29 09:34:27 SK kernel: [  260.871652]   Tx Queue             <0>
Nov 29 09:34:27 SK kernel: [  260.871653]   TDH                  <8>
Nov 29 09:34:27 SK kernel: [  260.871654]   TDT                  <8>
Nov 29 09:34:27 SK kernel: [  260.871655]   next_to_use          <8>
Nov 29 09:34:27 SK kernel: [  260.871656]   next_to_clean        <0>
Nov 29 09:34:27 SK kernel: [  260.871657] buffer_info[next_to_clean]
Nov 29 09:34:27 SK kernel: [  260.871658]   time_stamp           <ffffc1d7>
Nov 29 09:34:27 SK kernel: [  260.871659]   next_to_watch        <0>
Nov 29 09:34:27 SK kernel: [  260.871659]   jiffies              <ffffcc0d>
Nov 29 09:34:27 SK kernel: [  260.871660]   next_to_watch.status <0>

This hardware works flawlessly under 32bit. I get no errors and I have had no problems at all. I have two network cards, this 10/100/1000 and a 10/100; they are both set for DHCP. If I boot up with a network cable in the 10/100/1000 card, I get a bunch of error messages on boot and after I log in I get a message saying that Debian has just recovered from a kernel panic and to send the results to kernelopps.org (I did this once). If I reboot and remove the network cable it boots just fine. Regardless of how I booted, it never grabs a DHCP request in 64 bit mode and I get the errors posted above. If I assign an IP, I still get these errors. Again this works perfect in 32bit mode; no problems at all.


I have not found satisfactory answers in my Google searches so I am asking this list, can anyone help me resolve these issues? 

Thank you! I appreciate it!


Reply to: