From owner-freebsd-amd64@FreeBSD.ORG Fri Sep 16 21:27:24 2005 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6599216A41F for ; Fri, 16 Sep 2005 21:27:24 +0000 (GMT) (envelope-from sl151@waikato.ac.nz) Received: from newman.its.waikato.ac.nz (newman.its.waikato.ac.nz [130.217.66.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAE4743D46 for ; Fri, 16 Sep 2005 21:27:22 +0000 (GMT) (envelope-from sl151@waikato.ac.nz) Received: from ex4.its.waikato.ac.nz (ex4.its.waikato.ac.nz [130.217.70.144]) by newman.its.waikato.ac.nz (Postfix) with ESMTP id 00CCF1279C8 for ; Sat, 17 Sep 2005 09:27:21 +1200 (NZST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5BB05.6BD48F3A" Date: Sat, 17 Sep 2005 09:27:03 +1200 Message-ID: <53EF8EA01F1F5241BAB680A851B4F03F1E1224@ex4.its.waikato.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: <53EF8EA01F1F5241BAB680A851B4F03F1E1224@ex4.its.waikato.ac.nz> Thread-Topic: freebsd-amd64 Digest, Vol 119, Issue 5 Thread-Index: AcW6tlvGE/p8DeZDSJ6FhRvTV/dB4QATwXQj From: "Lin, Shih-Min" To: , X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: freebsd-amd64 Digest, Vol 119, Issue 5 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2005 21:27:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BB05.6BD48F3A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: owner-freebsd-amd64@freebsd.org on behalf of = freebsd-amd64-request@freebsd.org Sent: Sat 9/17/2005 12:00 AM To: freebsd-amd64@freebsd.org Subject: freebsd-amd64 Digest, Vol 119, Issue 5 =20 Send freebsd-amd64 mailing list submissions to freebsd-amd64@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 or, via email, send a message with subject or body 'help' to freebsd-amd64-request@freebsd.org You can reach the person managing the list at freebsd-amd64-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-amd64 digest..." Today's Topics: 1. amd64 Radeon 9000 nForce3 250 agp support - Yes and No (K. Wieland) 2. Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No (Ganael Laplanche) 3. Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No (Jung-uk Kim) 4. Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No (Adam Gregoire) 5. Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No (John-Mark Gurney) 6. building/porting linux SIS965L driver (Jeff D. Hamann) 7. acpi/ohci/rsdt wtf? (Jeff D. Hamann) 8. Re: acpi/ohci/rsdt wtf? (John Baldwin) 9. [PATCH] agp(4) for ULi M1689/nVidia nForce3 (Jung-uk Kim) 10. amd64/86199: Missed AMD64 motherboard (Mike Smith) 11. Problem with hp zv6000 (pier) 12. Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No (Ganael Laplanche) 13. Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No (Ganael Laplanche) 14. Re: amd64/86199: Missed AMD64 motherboard (Adriaan de Groot) 15. Re: acpi/ohci/rsdt wtf? (Bruno Ducrot) 16. Re: FAST_IPSEC on EMT64 / AMD64 (Michael VInce) ---------------------------------------------------------------------- Message: 1 Date: Thu, 15 Sep 2005 09:22:26 -0500 From: K. Wieland Subject: amd64 Radeon 9000 nForce3 250 agp support - Yes and No To: Jung-uk Kim Cc: freebsd-amd64@freebsd.org Message-ID: <4efa8eff718166b299f7d6a317011a37@gmail.com> Content-Type: text/plain; charset=3DUS-ASCII; delsp=3Dyes; = format=3Dflowed Jung-uk and fellow amd64 subscribers, I tried upgrading to 6.0B4 last night, after spending several nights =20 reading the documentation. I have been reading and am subscribed to =20 the amd64 list, so I figure I might as well try it! First, I mounted the new 6.0_B4 CD under 5.4 and tried to run the =20 sysinstall that way as outlined in the docs (I don't remember where, =20 but I can get the reference). sysinstall (v6.0 B4) would not run, =20 complaining about some libraries not being present (I had a previous =20 version of the libraries it was looking for, so I made sym links (bad, =20 I know!) but it failed looking for the next library, so I deleted the =20 symlink, and decided to reboot with the CD. I rebooted, went into fixit and did a dmesg. AGP was there, and the =20 device /dev/agpart existed. I was happy, and decided to upgrade to 6.0 = beta4 using the upgrade option in sysinstall. I didn't remember the =20 mount points for the various file systems so I had to boot back into =20 5.4 and write it all down (it would be nice if this was in the =20 documentation)! Anyway, I upgraded and rebooted. The first thing I noticed was the =20 generic kernel detected my com port, but didn't create a /dev/cuaa0 (I =20 dial up for internet). And, because I want sound and my TV card (bktr) = I decided to customize the kernel like I had done in 5.4. So, I did a diff of the GENERIC to the custom kernel, MYKERNEL, and =20 found that it was basically the same (MYKERNEL had the sound, bktr, and = agp with several extraneous things commented out). I built the new =20 kernel, installed it and rebooted. AGP was gone! I thought, well =20 maybe you don't need "device agp" in the kernel (I didn't see it in the = GENERIC, and agp loaded with that), so I tried that...still no AGP. =20 Then, I decided to use the GENERIC and see if that worked---still no =20 AGP. But, if I boot up with the CD, AGP is back! The confusing part to me is that the uname -a still gives me RELENG5.4 =20 -p7. That seems strange to me. The ps command also didn't work as =20 expected (just prints the headers, none of the processes). I read that if your sources don't match your kernel, you can get weird =20 stuff like this, so I went to cvsup to the most recent. BUT, in the =20 /usr/share/examples/standard-cvsup files it still had RELENG 5.4. I =20 went ahead and cvsup'ed anyway. I don't have anything critical on the drive, so I am tempted to wipe it = clean and reinstall (ala windows style) but I would really like to =20 understand what is going on here. I am CCing the freebsd-amd64 list in case they have some insights, too. Thanks, Kristopher Wieland Graduate Student Washington University in St. Louis Dept. of Physics- Compton Hall On Sep 13, 2005, at 11:40 AM, Jung-uk Kim wrote: > On Tuesday 13 September 2005 12:19 pm, K Wieland wrote: >> Thanks again for the quick reply. > > No problem. > >> Is there a "best method" for installing another version? I would >> rather not loose the kernel config, etc. Is it best to just wipe >> everything and start over? > > cvsup, buildworld, installworld, mergemaster... But it's quite a > hassle for new users. First of all, if the only problem for you is > the agp, try booting from the ISO, select Fixit, select CD/DVD, then > you will get shell. You can see if agp is probed/attached from > there. If that's there, you have two choices: > > 1. Upgrade. > 2. Patch kernel to add support for the AGP device. > > If you choose option 2, the only thing you really need is this: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/agp_amd64.c.diff?=20 > r1=3D1.6&r2=3D1.7 > > Good luck, > > JK > >> I'll give it a try and see how it goes! >> >> Kristopher >> >> On Sep 13, 2005, at 10:17 AM, Jung-uk Kim wrote: >>> On Tuesday 13 September 2005 11:06 am, K. Wieland wrote: >>>> Thank you for your quick reply! >>>> >>>> Yes, I am using 5.4 Release. I guess since I was just starting >>>> out with Freebsd, I'd go with "release" vs. stable or current. >>>> >>>> Do you know an ftp site for getting the images for 6.0 beta4? >>>> Or should I just cvsup to it? You can tell I am new, new new! >>> >>> ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/6.0/ >>> >>> JK >>> >>>> Thanks, >>>> >>>> Kristopher >>>> >>>> On Sep 13, 2005, at 9:54 AM, Jung-uk Kim wrote: >>>>> On Tuesday 13 September 2005 10:42 am, K. Wieland wrote: >>>>>> Hello Jung-uk! >>>>>> >>>>>> I was reading through the archives of the freebsd-amd64 >>>>>> archives (I am a new Freebsd user) and I have the exact same >>>>>> problem that you and Geneal talked about. >>>>>> >>>>>> I also have a radeon 9000 with a nForce3 250 chipset that does >>>>>> not detect the agp, even though it is in the kernel. >>>>>> >>>>>> Did you ever get this issue resolved? >>>>> >>>>> Are you using FreeBSD 5.4 or something? Try 6.0BETA4. It >>>>> should be fine. >>>>> >>>>> JK >>>>> >>>>>> Thank you, >>>>>> >>>>>> Kristopher Wieland > ------------------------------ Message: 2 Date: Thu, 15 Sep 2005 15:53:13 +0000 From: "Ganael Laplanche" Subject: Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No To: K.Wieland , Jung-uk Kim Cc: freebsd-amd64@freebsd.org Message-ID: <20050915155131.M39844@martymac.com> Content-Type: text/plain; charset=3Diso-8859-1 Hi all, I tried beta-1 with Radeon 9000 pro and nforce3-250gb, but system hangs = during X bootup. I had to go back to the goold old driver from 5.x :( The PR is here : http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/84015 Any clue ? Gana=EBl LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com Tel : (+33)6.84.03.57.24. ---------- Original Message ----------- From: K.Wieland To: Jung-uk Kim Cc: freebsd-amd64@freebsd.org Sent: Thu, 15 Sep 2005 09:22:26 -0500 Subject: amd64 Radeon 9000 nForce3 250 agp support - Yes and No > Jung-uk and fellow amd64 subscribers, >=20 > I tried upgrading to 6.0B4 last night, after spending several nights =20 > reading the documentation. I have been reading and am subscribed to =20 > the amd64 list, so I figure I might as well try it! >=20 > First, I mounted the new 6.0_B4 CD under 5.4 and tried to run the =20 > sysinstall that way as outlined in the docs (I don't remember where, =20 > but I can get the reference). sysinstall (v6.0 B4) would not run, =20 > complaining about some libraries not being present (I had a previous =20 > version of the libraries it was looking for, so I made sym links (bad, = > I know!) but it failed looking for the next library, so I deleted the = > symlink, and decided to reboot with the CD. >=20 > I rebooted, went into fixit and did a dmesg. AGP was there, and the =20 > device /dev/agpart existed. I was happy, and decided to upgrade to=20 > 6.0 beta4 using the upgrade option in sysinstall. I didn't remember=20 > the mount points for the various file systems so I had to boot back=20 > into =20 > 5.4 and write it all down (it would be nice if this was in the=20 > documentation)! >=20 > Anyway, I upgraded and rebooted. The first thing I noticed was the =20 > generic kernel detected my com port, but didn't create a /dev/cuaa0 (I = > dial up for internet). And, because I want sound and my TV card=20 > (bktr) I decided to customize the kernel like I had done in 5.4. >=20 > So, I did a diff of the GENERIC to the custom kernel, MYKERNEL, and =20 > found that it was basically the same (MYKERNEL had the sound, bktr, > and agp with several extraneous things commented out). I built the=20 > new kernel, installed it and rebooted. AGP was gone! I thought,=20 > well maybe you don't need "device agp" in the kernel (I didn't see it = > in the GENERIC, and agp loaded with that), so I tried that...still no = > AGP. Then, I decided to use the GENERIC and see if that worked--- > still no AGP. But, if I boot up with the CD, AGP is back! >=20 > The confusing part to me is that the uname -a still gives me RELENG5.4 = > -p7. That seems strange to me. The ps command also didn't work as=20 > expected (just prints the headers, none of the processes). >=20 > I read that if your sources don't match your kernel, you can get weird = > stuff like this, so I went to cvsup to the most recent. BUT, in the = > /usr/share/examples/standard-cvsup files it still had RELENG 5.4. I=20 > went ahead and cvsup'ed anyway. >=20 > I don't have anything critical on the drive, so I am tempted to wipe=20 > it clean and reinstall (ala windows style) but I would really like to = > understand what is going on here. >=20 > I am CCing the freebsd-amd64 list in case they have some insights, = too. >=20 > Thanks, >=20 > Kristopher Wieland > Graduate Student > Washington University in St. Louis > Dept. of Physics- Compton Hall > On Sep 13, 2005, at 11:40 AM, Jung-uk Kim wrote: >=20 > > On Tuesday 13 September 2005 12:19 pm, K Wieland wrote: > >> Thanks again for the quick reply. > > > > No problem. > > > >> Is there a "best method" for installing another version? I would > >> rather not loose the kernel config, etc. Is it best to just wipe > >> everything and start over? > > > > cvsup, buildworld, installworld, mergemaster... But it's quite a > > hassle for new users. First of all, if the only problem for you is > > the agp, try booting from the ISO, select Fixit, select CD/DVD, then > > you will get shell. You can see if agp is probed/attached from > > there. If that's there, you have two choices: > > > > 1. Upgrade. > > 2. Patch kernel to add support for the AGP device. > > > > If you choose option 2, the only thing you really need is this: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/agp_amd64.c.diff?=20 > > r1=3D1.6&r2=3D1.7 > > > > Good luck, > > > > JK > > > >> I'll give it a try and see how it goes! > >> > >> Kristopher > >> > >> On Sep 13, 2005, at 10:17 AM, Jung-uk Kim wrote: > >>> On Tuesday 13 September 2005 11:06 am, K. Wieland wrote: > >>>> Thank you for your quick reply! > >>>> > >>>> Yes, I am using 5.4 Release. I guess since I was just starting > >>>> out with Freebsd, I'd go with "release" vs. stable or current. > >>>> > >>>> Do you know an ftp site for getting the images for 6.0 beta4? > >>>> Or should I just cvsup to it? You can tell I am new, new new! > >>> > >>> ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/6.0/ > >>> > >>> JK > >>> > >>>> Thanks, > >>>> > >>>> Kristopher > >>>> > >>>> On Sep 13, 2005, at 9:54 AM, Jung-uk Kim wrote: > >>>>> On Tuesday 13 September 2005 10:42 am, K. Wieland wrote: > >>>>>> Hello Jung-uk! > >>>>>> > >>>>>> I was reading through the archives of the freebsd-amd64 > >>>>>> archives (I am a new Freebsd user) and I have the exact same > >>>>>> problem that you and Geneal talked about. > >>>>>> > >>>>>> I also have a radeon 9000 with a nForce3 250 chipset that does > >>>>>> not detect the agp, even though it is in the kernel. > >>>>>> > >>>>>> Did you ever get this issue resolved? > >>>>> > >>>>> Are you using FreeBSD 5.4 or something? Try 6.0BETA4. It > >>>>> should be fine. > >>>>> > >>>>> JK > >>>>> > >>>>>> Thank you, > >>>>>> > >>>>>> Kristopher Wieland > > >=20 > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to = "freebsd-amd64-unsubscribe@freebsd.org" ------- End of Original Message ------- ------------------------------ Message: 3 Date: Thu, 15 Sep 2005 12:19:53 -0400 From: Jung-uk Kim Subject: Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No To: "Ganael Laplanche" Cc: freebsd-amd64@FreeBSD.org, "K.Wieland" Message-ID: <200509151219.55989.jkim@FreeBSD.org> Content-Type: text/plain; charset=3D"utf-8" On Thursday 15 September 2005 11:53 am, Ganael Laplanche wrote: > Hi all, > > I tried beta-1 with Radeon 9000 pro and nforce3-250gb, but system > hangs during X bootup. I had to go back to the goold old driver > from 5.x :( The 'good old' driver uses generic nForce AGP interface. If the=20 driver really works, I will be surprised. I admit agp_amd64.c=20 requires more work (esp. chipset-specific handling including nForce)=20 but I had no time/hardware. Anyway you have to make sure agp(4) really works for you. http://docs.freebsd.org/cgi/mid.cgi?200405181244.28716.jkim > The PR is here : > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/84015 > > Any clue ? Have you tried xorg-server-snap? If it doesn't work, can you try=20 this? http://people.freebsd.org/~jkim/xorg-server-snap.diff Thanks, Jung-uk Kim > Gana=EF=BF=BDl LAPLANCHE > ganael.laplanche@martymac.com > http://www.martymac.com > Tel : (+33)6.84.03.57.24. ------------------------------ Message: 4 Date: Thu, 15 Sep 2005 12:29:37 -0400 From: Adam Gregoire Subject: Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No To: freebsd-amd64@freebsd.org Cc: "K.Wieland" Message-ID: <1126801777.7412.7.camel@S0106c0ffeec0ffee.su.shawcable.net> Content-Type: text/plain Hello, this chipset is not supported for agpgart, the nforce3 250 chipset has the code needed to detect the gart but is missing functionality needed for proper operation. See also, PR amd64/71753 and the following thread http://lists.freebsd.org/pipermail/freebsd-amd64/2005-April/004300.html Regards, --=20 Adam Gregoire ------------------------------ Message: 5 Date: Thu, 15 Sep 2005 10:19:04 -0700 From: John-Mark Gurney Subject: Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No To: "K. Wieland" Cc: freebsd-amd64@FreeBSD.org, Jung-uk Kim Message-ID: <20050915171904.GT793@funkthat.com> Content-Type: text/plain; charset=3Dus-ascii K. Wieland wrote this message on Thu, Sep 15, 2005 at 09:22 -0500: > Anyway, I upgraded and rebooted. The first thing I noticed was the =20 > generic kernel detected my com port, but didn't create a /dev/cuaa0 (I = =20 > dial up for internet). And, because I want sound and my TV card = (bktr) =20 > I decided to customize the kernel like I had done in 5.4. These have been renamed to match the tty versions.. look for /dev/cuad0 instead... --=20 John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ------------------------------ Message: 6 Date: Thu, 15 Sep 2005 10:27:16 -0700 From: "Jeff D. Hamann" Subject: building/porting linux SIS965L driver To: , Message-ID: <001d01c5ba1a$bc83fdd0$0a00a8c0@rodan> Content-Type: text/plain; format=3Dflowed; charset=3D"iso-8859-1"; reply-type=3Doriginal I'm building (or trying to build) an amd64 FreeBSD machine to replace my = FreeBSD 4.4 server. I purchased an ASUS Vintage-AE1 MB that uses the=20 following chipsets: Northbridge: SiS760GX Southbridge: SiS965L I've not been able to get the on-board NIC to light up, so I purchased=20 another NIC which works alright. It's bothering me too much that the = chipset=20 isn't supported = (http://www.freebsd.org/platforms/amd64/motherboards.html)=20 but many of the other ASUS MB chipsets are. This seems like a great = machine=20 and I suspect there are plenty more machines that will be using this=20 barebones box as a starting place (of course, I'll be wrong in a year=20 anyways). I've found the linux driver for the on-board NIC and since = I've=20 never ported a driver for FreeBSD, I'm trying to figure out how much = work it=20 will be to port the driver to FreeBSD-6.0? I've snooped around in the /usr/src/sys/pci/if_sis.c /usr/src/sys/pci/if_sisreg.h 6.0Beta4 files to simply examine the bsd code. To my novice eyes, the = files=20 look completely different from the linux drivers and I'm not sure I can=20 takle this myself since I've never done anything like this. Can someone = help=20 me through this process, or is this not worth the trouble? Jeff. --- Jeff D. Hamann Forest Informatics, Inc. PO Box 1421 Corvallis, Oregon USA 97339-1421 541-754-1428 jeff.hamann@forestinformatics.com www.forestinformatics.com ------------------------------ Message: 7 Date: Thu, 15 Sep 2005 12:41:18 -0700 From: "Jeff D. Hamann" Subject: acpi/ohci/rsdt wtf? To: Message-ID: <000b01c5ba2d$7a6fa940$0a00a8c0@rodan> Content-Type: text/plain; format=3Dflowed; charset=3D"iso-8859-1"; reply-type=3Doriginal I'm curious what the acpi_perf0: invalid _PSS package messages are all about and why there are so many? I'm also curious about = the=20 EHCI stuff. My bios has some settings which state: "stop ehci in ohci handler handover" the comments for the setting stats: "stops the ehci host controller during ohci handvoer call. the is needed = for=20 installing Oses that does not support ehci host controllers" and I'm not sure what it means and I don't know if FreeBSD-6beta4 = supports=20 it. Also, there's another setting about "acpi apic support" where the hint=20 states: "include acpi apic table pointer to rsdt pointer list" Wha? I've included my dmesg output for diagnostics. $ dmesg Copyright (c) 1992-2005 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 6.0-BETA4 #1: Fri Sep 16 06:41:12 PDT 2005 root@bobby.forestinformatics.com:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3000+ (1995.01-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0xf4a Stepping =3D 10 = Features=3D0x78bfbff AMD Features=3D0xe0500800 real memory =3D 1039400960 (991 MB) avail memory =3D 991444992 (945 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 0 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: irq 5 on acpi0 pci_link3: irq 10 on acpi0 pci_link4: irq 11 on acpi0 pci_link5: irq 5 on acpi0 pci_link6: irq 11 on acpi0 pci_link7: irq 5 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package acpi_perf0: invalid _PSS package pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port=20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 2.5 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 2.7 (no driver attached) ohci0: mem 0xfbefc000-0xfbefcfff irq 20 at = device=20 3.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfbefd000-0xfbefdfff irq 21 at = device=20 3.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ohci2: mem 0xfbefe000-0xfbefefff irq 22 at = device=20 3.2 on pci0 ohci2: [GIANT-LOCKED] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfbeff000-0xfbefffff irq = 23=20 at device 3.3 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 3 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: SiS EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 8 ports with 8 removable, self powered pci0: at device 4.0 (no driver attached) pcib2: at device 6.0 on pci0 pci2: on pcib2 pcib3: at device 7.0 on pci0 pci3: on pcib3 rl0: port 0xa800-0xa8ff mem=20 0xfbefb800-0xfbefb8ff irq 17 at device 10.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:11:95:24:60:b3 acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on=20 acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 = on=20 acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq = 3=20 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 Timecounter "TSC" frequency 1995008941 Hz quality 800 Timecounters tick every 1.000 msec ad0: 190782MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA66 Trying to mount root from ufs:/dev/ad0s1a $ jeff. --- Jeff D. Hamann Forest Informatics, Inc. PO Box 1421 Corvallis, Oregon USA 97339-1421 541-754-1428 jeff.hamann@forestinformatics.com www.forestinformatics.com ------------------------------ Message: 8 Date: Thu, 15 Sep 2005 16:00:49 -0400 From: John Baldwin Subject: Re: acpi/ohci/rsdt wtf? To: freebsd-amd64@freebsd.org, "Jeff D. Hamann" Message-ID: <200509151600.50793.jhb@FreeBSD.org> Content-Type: text/plain; charset=3D"iso-8859-1" On Thursday 15 September 2005 03:41 pm, Jeff D. Hamann wrote: > I'm curious what the > > acpi_perf0: invalid _PSS package > > messages are all about and why there are so many? I'm also curious = about > the EHCI stuff. My bios has some settings which state: > > "stop ehci in ohci handler handover" > > the comments for the setting stats: > > "stops the ehci host controller during ohci handvoer call. the is = needed > for installing Oses that does not support ehci host controllers" Leave it off. FreeBSD 6 includes the ehci(4) driver by default as you = can see=20 in your dmesg. > and I'm not sure what it means and I don't know if FreeBSD-6beta4 = supports > it. > > Also, there's another setting about "acpi apic support" where the hint > states: > > "include acpi apic table pointer to rsdt pointer list" > > Wha? Leave that on. It looks like it already is. Having this on is what = let's us=20 find the ACPI APIC Table as mentioned here: > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard --=20 John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org ------------------------------ Message: 9 Date: Thu, 15 Sep 2005 19:57:04 -0400 From: Jung-uk Kim Subject: [PATCH] agp(4) for ULi M1689/nVidia nForce3 To: freebsd-amd64@FreeBSD.org Message-ID: <200509151957.24837.jkim@FreeBSD.org> Content-Type: text/plain; charset=3D"us-ascii" If you have any of these, please test and let me know. http://people.freebsd.org/~jkim/agp_amd64.diff FYI, agp(4) GART test is here: http://people.freebsd.org/~jkim/testgart.c Thanks, Jung-uk Kim ------------------------------ Message: 10 Date: Fri, 16 Sep 2005 03:48:18 GMT From: Mike Smith Subject: amd64/86199: Missed AMD64 motherboard To: freebsd-gnats-submit@FreeBSD.org Message-ID: <200509160348.j8G3mIH5015714@www.freebsd.org> >Number: 86199 >Category: amd64 >Synopsis: Missed AMD64 motherboard >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: =20 >Keywords: =20 >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 16 03:50:08 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Mike Smith >Release: FreeBSD 5.4-STABLE >Organization: none >Environment: FreeBSD insomnia.localnet.net 5.4-STABLE FreeBSD 5.4-STABLE #5: Thu Sep = 15 15:24:53 CDT 2005 = perlfu@insomnia.localnet.net:/usr/obj/usr/src/sys/INSOMNIA amd64 >Description: MSI K8M NEO-V is not listed in the section covering amd64 = compatible motherboards. Also there seems to be a lack of support for = the VT8237 SATA Raid controller. I can use the drive, but there seems = to be some shaky behavior coming from it. I've seen random kernel = panics related to the drive, (don't have them to paste currently, but if = you give me some time I'm sure it will randomly pop up some time soon). = It also defers for background fsck'ing even if the drives were properly = unmounted. The onboard sound also results in hard locks, randomly, = especially when vchans are enabled. I'm using the VT8237 Audio as well. = Any help with this would be greatly appreciated. >How-To-Repeat: Errors occur fairly randomly, and present themselves in different = manners each time. The drive can do everything from cause a panic, = (same one each time, seems to indicate inconsistancies on the drive). = Also shows itself by constantly appearing as improperly dismounted, even = when shutdown, or reboot was called. Sound causes hard locks quite = frequently and randomly as far as I can tell. It only hard locks when I = try to play multiple sounds at once. Have tried with and without = hw.snd.maxautovchans=3D4, tried a few of the patches that came out on = the lists to no avail, no error messages, or logs can be found with = anything pertaining to the sound issue, apparently it is generally a = 100% hard lock, keyboard failure and all. >Fix: =20 >Release-Note: >Audit-Trail: >Unformatted: ------------------------------ Message: 11 Date: Fri, 16 Sep 2005 07:58:04 +0200 From: pier Subject: Problem with hp zv6000 To: freebsd-amd64@freebsd.org Message-ID: <432A5EEC.9020202@yahoo.it> Content-Type: text/plain; charset=3D"iso-8859-15" Hi all. I'm having so many troubles that i have almost gave up to install FreeBSD on this notebook (amd64 3500+, chipset ATI Xpress200). I tried all the releases, from 5.3 to 6.0-BETA4 but no one works. I read something here that could be interesting: http://forums.bit-tech.net/showthread.php?t=3D94652 I tried to look for this functions in the code, but it looks like in the new releases they don't exist. So...now i can boot with the kernel installed with this personalized boot-cd (http://blackk.union.edu/~black/freebsd/5_3_30Dec2004-amd64-miniinst.iso)= but i can't update my kernel with a newer one. What can I do? Thank you Pier -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : = http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050916/9b8= 58fc7/signature-0001.bin ------------------------------ Message: 12 Date: Fri, 16 Sep 2005 08:04:28 +0000 From: "Ganael Laplanche" Subject: Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No To: Jung-uk Kim Cc: freebsd-amd64@FreeBSD.org, "K.Wieland" Message-ID: <20050916080048.M77239@martymac.com> Content-Type: text/plain; charset=3Diso-8859-1 > On Thursday 15 September 2005 11:53 am, Ganael Laplanche wrote: > > Hi all, > > > > I tried beta-1 with Radeon 9000 pro and nforce3-250gb, but system > > hangs during X bootup. I had to go back to the goold old driver > > from 5.x :( >=20 > The 'good old' driver uses generic nForce AGP interface. If the=20 > driver really works, I will be surprised. I admit agp_amd64.c=20 > requires more work (esp. chipset-specific handling including nForce)=20 > but I had no time/hardware. >=20 > Anyway you have to make sure agp(4) really works for you. > Hi again, No, I have no agp support, but using the old driver allows me to start = X... I remember using the new driver made a /dev/agpgart appear, but the system = crashes at X startup... =20 > http://docs.freebsd.org/cgi/mid.cgi?200405181244.28716.jkim >=20 > > The PR is here : > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/84015 > > > > Any clue ? >=20 > Have you tried xorg-server-snap? If it doesn't work, can you try=20 > this? No, I didn't, but I think I'll have the same pb since agp code for = nforce3-250 is not correct in the kernel :( > http://people.freebsd.org/~jkim/xorg-server-snap.diff >=20 > Thanks, Thanks to you, Regards, Ganael. > Jung-uk Kim >=20 > > [UTF-8?]Gana=EF=BF=BDl LAPLANCHE > > ganael.laplanche@martymac.com > > http://www.martymac.com > > Tel : (+33)6.84.03.57.24. ------- End of Original Message ------- ------------------------------ Message: 13 Date: Fri, 16 Sep 2005 08:08:54 +0000 From: "Ganael Laplanche" Subject: Re: amd64 Radeon 9000 nForce3 250 agp support - Yes and No To: Adam Gregoire , freebsd-amd64@freebsd.org Cc: "K.Wieland" Message-ID: <20050916080443.M8613@martymac.com> Content-Type: text/plain; charset=3Diso-8859-1 > Hello, this chipset is not supported for agpgart, the nforce3 250 > chipset has the code needed to detect the gart but is missing > functionality needed for proper operation. >=20 > See also, PR amd64/71753 and the following thread > = http://lists.freebsd.org/pipermail/freebsd-amd64/2005-April/004300.html I'm the author of this post... I tried to write a small patch to see = what's happening with it, but it made my system hang as described here http://lists.freebsd.org/pipermail/freebsd-amd64/2005-April/004315.html = ! And It looks like this code has been included in the 6-0 branch :(, that's why = you should use the old 5.x drivers... > Regards, >=20 > --=20 > Adam Gregoire >=20 > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to = "freebsd-amd64-unsubscribe@freebsd.org" ------- End of Original Message ------- ------------------------------ Message: 14 Date: Fri, 16 Sep 2005 11:37:14 +0200 From: Adriaan de Groot Subject: Re: amd64/86199: Missed AMD64 motherboard To: freebsd-amd64@freebsd.org Message-ID: <200509161137.14570.groot@kde.org> Content-Type: text/plain; charset=3D"iso-8859-1" On Friday 16 September 2005 05:48, Mike Smith wrote: > MSI K8M NEO-V is not listed in the section covering amd64 = compatible > motherboards. =20 That's one issue, which should be PR-ed as described on the motherboards = page. > Also there seems to be a lack of support for the VT8237 SATA=20 > Raid controller. =20 Er, you mean atapci1@pci0:15:0: class=3D0x010400 card=3D0x80ed1043 = chip=3D0x31491106=20 rev=3D0x80 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT8237 VT6410 SATA RAID Controller' class =3D mass storage subclass =3D RAID That one? It works just fine on Asus & Gigabyte boards. > onboard sound also results in hard locks, randomly, especially when = vchans > are enabled. I'm using the VT8237 Audio as well. Any help with this = would > be greatly appreciated. I've managed to lock my Asus board once with mpg123 foo.mp3 & mpg123 = foo.mp3,=20 but sound in general is fine as well. --=20 These are your friends - Adem GPG: FEA2 A3FE Adriaan de Groot ------------------------------ Message: 15 Date: Fri, 16 Sep 2005 12:12:57 +0200 From: Bruno Ducrot Subject: Re: acpi/ohci/rsdt wtf? To: "Jeff D. Hamann" Cc: freebsd-amd64@freebsd.org Message-ID: <20050916101257.GA12562@poupinou.org> Content-Type: text/plain; charset=3Dus-ascii On Thu, Sep 15, 2005 at 12:41:18PM -0700, Jeff D. Hamann wrote: > I'm curious what the >=20 > acpi_perf0: invalid _PSS package >=20 > messages are all about and why there are so many? Could you send to me the output from acpidump -dt It's rather large. Please send it to me privately or better provide some link. Cheers, --=20 Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ------------------------------ Message: 16 Date: Fri, 16 Sep 2005 20:16:24 +1000 From: Michael VInce Subject: Re: FAST_IPSEC on EMT64 / AMD64 To: "Bjoern A. Zeeb" Cc: freebsd-amd64@FreeBSD.org, Kris Kennaway Message-ID: <432A9B78.8020906@roq.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Michael VInce wrote: > Bjoern A. Zeeb wrote: > >> On Mon, 12 Sep 2005, Kris Kennaway wrote: >> >> =20 >> >>> On Mon, Sep 12, 2005 at 11:56:58AM +1000, Michael VInce wrote: >>> =20 >>> >>>> Hi guys, >>>> I am getting a Intel Xeon based EMT64 server as a gateway that may = in >>>> the future do some VPN, >>>> I wondered if the EMT64 servers could run FAST_IPSEC under AMD64=20 >>>> FreeBSD. >>>> With these options below compiled into the kernel I was able to = boot >>>> FreeBSD with no panics if I booted into single user mode and then = just >>>> did 'exit' to go back to regular boot, otherwise it would panic as = if >>>> it was an AMD64 CPU. >>>> =20 >>> >>> You forgot to include details of the panic. >>> =20 >> >> >> That would be really good to know. >> >> Then we'd finally know more than was given in >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Damd64/73211 >> =20 >> > > Sorry instead of getting a core dump I grabbed a FreeBSD AMD64 beta4=20 > 6.0 ISO and put it on this server. > But I do have some good news in what I found. > Recompiled FAST_IPSEC into the kernel and rebooted it, it came up = fine.. > So then put in some ipsec security policies into /etc/ipsec.conf > ipsec_enable=3D"YES" > and ran /etc/rc.d/ipsec start > and it ran fine. > I then installed ipsec-tools and loaded up the racoon daemon this also = > triggers a panic on my FreeBSD AMD64 6.0 laptop with out FAST_IPSEC=20 > being compiled into the kernel and its loaded up fine. > This looks all completely solid. I haven't been able to panic the=20 > server with a full VPN configuration activated. > The only thing I haven't done is tested if the IPSEC VPN actually can=20 > work. > > This is no mistake this is AMD64 kernel FreeBSD with FAST_IPSEC I just = > cheated using the Intel EMT64 > > Regards, > Mike > > beast# /sbin/sysctl -a | grep ipsec > ipsecpolicy 16 4K - 520 256 > ipsecrequest 2 1K - 4 256 > ipsec-reg 3 1K - 24 32 > net.inet.ipsec.def_policy: 1 > net.inet.ipsec.esp_trans_deflev: 1 > net.inet.ipsec.esp_net_deflev: 1 > net.inet.ipsec.ah_trans_deflev: 1 > net.inet.ipsec.ah_net_deflev: 1 > net.inet.ipsec.ah_cleartos: 1 > net.inet.ipsec.ah_offsetmask: 0 > net.inet.ipsec.dfbit: 0 > net.inet.ipsec.ecn: 0 > net.inet.ipsec.debug: 0 > net.inet.ipsec.esp_randpad: -1 > net.inet.ipsec.crypto_support: 0 > net.inet6.ipsec6.def_policy: 1 > net.inet6.ipsec6.esp_trans_deflev: 1 > net.inet6.ipsec6.esp_net_deflev: 1 > net.inet6.ipsec6.ah_trans_deflev: 1 > net.inet6.ipsec6.ah_net_deflev: 1 > net.inet6.ipsec6.ecn: 0 > net.inet6.ipsec6.debug: 0 > net.inet6.ipsec6.esp_randpad: -1 > beast# uname -a > FreeBSD beast 6.0-BETA4 FreeBSD 6.0-BETA4 #0: Mon Sep 12 20:40:05 UTC=20 > 2005 root@beast:/usr/obj/usr/src/sys/GENERIC_IPSEC amd64 > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to = "freebsd-amd64-unsubscribe@freebsd.org" I am back, I still would like to see this bug fixed (and I assume other people do=20 as well :) The server in my above email appears to be working fine using FAST_IPSEC = on AMD64 is a Dell 2850 (Beast) But on a Dell 1850 it crashes as usual, here is a dump on AMD64 6.0=20 Beta4 cvsuped from beta3 ISO install. I still don't know why it appears=20 to be working fine on a 2850 but not on any other machine in the world? This machine below is a Dell 1850 EMT64 with FAST_IPSEC compiled into it = with some rules in /etc/ipsec.conf I can get panics from starting ipsec or starting racoon ipsec-tools. The = I have listed 2 dumps here the first one is from racoon and the one=20 below is from setkey ( starting ipsec ) I don't really know much about doing this stuff so I have just run some=20 of the commands in the kernel debug handbook example. This dump was=20 triggered from starting racoon. This is from a usb2serial console output from the server. cd /usr/obj/usr/src/sys/GENERIC_IPSEC/ tank# kgdb kernel.debug /usr/crash/vmcore.7 [GDB will not be able to debug user-mode threads:=20 /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain=20 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: 0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 591 (racoon) panic: from debugger cpuid =3D 0 Uptime: 4m23s Dumping 2047 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 2047MB (523968 pages) 2031 2015 1999 1983 1967 1951 1935 1919 = 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695=20 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471=20 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247=20 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023=20 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 = 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447=20 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159=20 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=3Dr" (td)); (kgdb) list 167 static __inline struct thread * 168 __curthread(void) 169 { 170 struct thread *td; 171 172 __asm __volatile("movq %%gs:0,%0" : "=3Dr" (td)); 173 return (td); 174 } 175 #define curthread (__curthread()) 176 (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0xffffffff803b8ccc in boot (howto=3D260) at=20 /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff803b876b in panic (fmt=3D0xffffffff805faac2 "from = debugger")=20 at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xffffffff801aa1c2 in db_panic (addr=3D0, have_addr=3D0, count=3D0,=20 modif=3D0x0) at /usr/src/sys/ddb/db_command.c:435 #4 0xffffffff801aa705 in db_command_loop () at=20 /usr/src/sys/ddb/db_command.c:349 #5 0xffffffff801ac573 in db_trap (type=3D-1270872608, code=3D0) at=20 /usr/src/sys/ddb/db_main.c:221 #6 0xffffffff803d5799 in kdb_trap (type=3D12, code=3D0,=20 tf=3D0xffffffffb44007a0) at /usr/src/sys/kern/subr_kdb.c:473 #7 0xffffffff8059bf0e in trap_fatal (frame=3D0xffffffffb44007a0,=20 eva=3D18446742975788145024) at /usr/src/sys/amd64/amd64/trap.c:656 #8 0xffffffff8059c2a3 in trap_pfault (frame=3D0xffffffffb44007a0,=20 usermode=3D0) at /usr/src/sys/amd64/amd64/trap.c:581 #9 0xffffffff8059c4b9 in trap (frame=3D {tf_rdi =3D -2140943745, tf_rsi =3D 256, tf_rdx =3D -1270871712, = tf_rcx=20 =3D -2142535110, tf_r8 =3D 64, tf_r9 =3D -1097921406592, tf_rax =3D 0, = tf_rbx =3D=20 2152432187, tf_rbp =3D -1270871728, tf_r10 =3D -2139154144, tf_r11 =3D=20 -1270871552, tf_r12 =3D 57, tf_r13 =3D 0, tf_r14 =3D 0, tf_r15 =3D 0, = tf_trapno=20 =3D 12, tf_addr =3D -3413406822, tf_flags =3D -2140901446, tf_err =3D 0, = tf_rip=20 =3D -2142535096, tf_cs =3D 8, tf_rflags =3D 66178, tf_rsp =3D = -1270871968, tf_ss=20 =3D 16}) at /usr/src/sys/amd64/amd64/trap.c:360 #10 0xffffffff80589dfb in calltrap () at=20 /usr/src/sys/amd64/amd64/exception.S:168 #11 0xffffffff8063ca7f in wi_pccard_products () #12 0x0000000000000100 in ?? () #13 0xffffffffb4400960 in ?? () #14 0xffffffff804b823a in kdebug_mbuf (m0=3D0x0) at=20 /usr/src/sys/netipsec/key_debug.c:670 #15 0xffffffff80442d60 in raw_usend (so=3D0x0, flags=3D0, m=3D0x0, = nam=3D0x0,=20 control=3D0x0, td=3D0x0) at /usr/src/sys/net/raw_usrreq.c:263 #16 0xffffffff804b8d2a in key_send (so=3D0x0, flags=3D0, m=3D0x0, = nam=3D0x0,=20 control=3D0x0, td=3D0x0) at /usr/src/sys/netipsec/keysock.c:532 #17 0xffffffff803fdde4 in sosend (so=3D0xffffff005f41dc08, addr=3D0x0,=20 uio=3D0xffffffffb4400a80, top=3D0xffffff006076e700, control=3D0x0, = flags=3D0, td=3D0xffffff005ec8d980) at /usr/src/sys/kern/uipc_socket.c:829 #18 0xffffffff80404d54 in kern_sendit (td=3D0xffffff005ec8d980, s=3D5,=20 mp=3D0xffffffffb4400b50, flags=3D0, control=3D0x0, segflg=3D16) at /usr/src/sys/kern/uipc_syscalls.c:772 #19 0xffffffff80405f16 in sendit (td=3D0xffffff005ec8d980, s=3D5,=20 mp=3D0xffffffffb4400b50, flags=3D0) at = /usr/src/sys/kern/uipc_syscalls.c:712 #20 0xffffffff804062d4 in sendto (td=3D0x0, uap=3D0x0) at=20 /usr/src/sys/kern/uipc_syscalls.c:830 #21 0xffffffff8059cc72 in syscall (frame=3D {tf_rdi =3D 5, tf_rsi =3D 5677936, tf_rdx =3D 16, tf_rcx =3D 0, = tf_r8 =3D 0,=20 tf_r9 =3D 0, tf_rax =3D 133, tf_rbx =3D 5677952, tf_rbp =3D 2, tf_r10 = =3D 4,=20 tf_r11 =3D 582, tf_r12 =3D 5677936, tf_r13 =3D 7, tf_r14 =3D 5, tf_r15 = =3D 0,=20 tf_trapno =3D 12, tf_addr =3D 4292816, tf_flags =3D 0, tf_err =3D 2, = tf_rip =3D=20 34372796060, tf_cs =3D 43, tf_rflags =3D 582, tf_rsp =3D = 140737488349928,=20 tf_ss =3D 35}) at /usr/src/sys/amd64/amd64/trap.c:797 #22 0xffffffff80589f98 in Xfast_syscall () at=20 /usr/src/sys/amd64/amd64/exception.S:270 #23 0x0000000000000005 in ?? () #24 0x000000000056a370 in ?? () #25 0x0000000000000010 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000085 in ?? () #30 0x000000000056a380 in ?? () #31 0x0000000000000002 in ?? () #32 0x0000000000000004 in ?? () #33 0x0000000000000246 in ?? () #34 0x000000000056a370 in ?? () #35 0x0000000000000007 in ?? () #36 0x0000000000000005 in ?? () #37 0x0000000000000000 in ?? () #38 0x000000000000000c in ?? () #39 0x00000000004180d0 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000002 in ?? () #42 0x0000000800c73e9c in ?? () #43 0x000000000000002b in ?? () #44 0x0000000000000246 in ?? () #45 0x00007fffffffeae8 in ?? () #46 0x0000000000000023 in ?? () #47 0x00007fffffff5b50 in ?? () #48 0x0000000000000023 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x000000005f4dd000 in ?? () #58 0x0000000000000001 in ?? () #59 0x0000000000000000 in ?? () #60 0xffffff005e696340 in ?? () #61 0xffffff007b9b74c0 in ?? () #62 0xffffffffb4400260 in ?? () #63 0xffffffffb4400238 in ?? () #64 0xffffff005ec8d980 in ?? () #65 0xffffffff803cd10a in sched_switch (td=3D0x56a380, newtd=3D0x56a370, = flags=3D5) at /usr/src/sys/kern/sched_4bsd.c:973 Previous frame inner to this frame (corrupt stack?) Here is the serial console output from doing '/etc/rc.d/ipsec start'=20 with some rules in /etc/ipsec.conf Fatal trap 12: page fault while in kernel mode cpuid =3D 1; apic id =3D 01 fault virtual address =3D 0xffffffff3489ab9a fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xffffffff804b8248 stack pointer =3D 0x10:0xffffffffb43e2850 frame pointer =3D 0x10:0xffffffffb43e2950 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 615 (setkey) [thread pid 615 tid 100159 ] Stopped at kdebug_mbuf+0x88: db> panic panic: from debugger cpuid =3D 0 Uptime: 14m39s Dumping 2047 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 2047MB (523968 pages) 2031 2015 1999 1983 1967 1951 1935 1919 = 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695=20 1679 1663 16k Dump complete tank# kgdb kernel.debug /usr/crash/vmcore.8 kgdb kernel.debug /usr/crash/vmcore.8 [GDB will not be able to debug user-mode threads:=20 /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain=20 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "amd64-marcel-freebsd". Unread portion of the kernel message buffer: fff804b8248 stack pointer =3D 0x10:0xffffffffb43e2850 frame pointer =3D 0x10:0xffffffffb43e2950 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 615 (setkey) panic: from debugger cpuid =3D 0 Uptime: 14m39s Dumping 2047 MB (2 chunks) chunk 0: 1MB (156 pages) ... ok chunk 1: 2047MB (523968 pages) 2031 2015 1999 1983 1967 1951 1935 1919 = 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695=20 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471=20 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247=20 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023=20 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 = 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447=20 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159=20 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:172 172 __asm __volatile("movq %%gs:0,%0" : "=3Dr" (td)); (kgdb) list 167 static __inline struct thread * 168 __curthread(void) 169 { 170 struct thread *td; 171 172 __asm __volatile("movq %%gs:0,%0" : "=3Dr" (td)); 173 return (td); 174 } 175 #define curthread (__curthread()) 176 (kgdb) backtrace #0 doadump () at pcpu.h:172 #1 0xffffffff803b8ccc in boot (howto=3D260) at=20 /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff803b876b in panic (fmt=3D0xffffffff805faac2 "from = debugger")=20 at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xffffffff801aa1c2 in db_panic (addr=3D0, have_addr=3D0, count=3D0,=20 modif=3D0x0) at /usr/src/sys/ddb/db_command.c:435 #4 0xffffffff801aa705 in db_command_loop () at=20 /usr/src/sys/ddb/db_command.c:349 #5 0xffffffff801ac573 in db_trap (type=3D-1270995488, code=3D0) at=20 /usr/src/sys/ddb/db_main.c:221 #6 0xffffffff803d5799 in kdb_trap (type=3D12, code=3D0,=20 tf=3D0xffffffffb43e27a0) at /usr/src/sys/kern/subr_kdb.c:473 #7 0xffffffff8059bf0e in trap_fatal (frame=3D0xffffffffb43e27a0,=20 eva=3D18446742975772514688) at /usr/src/sys/amd64/amd64/trap.c:656 #8 0xffffffff8059c2a3 in trap_pfault (frame=3D0xffffffffb43e27a0,=20 usermode=3D0) at /usr/src/sys/amd64/amd64/trap.c:581 #9 0xffffffff8059c4b9 in trap (frame=3D {tf_rdi =3D -2140943745, tf_rsi =3D 256, tf_rdx =3D -1270994592, = tf_rcx=20 =3D -2142535110, tf_r8 =3D 64, tf_r9 =3D -1097937036928, tf_rax =3D 0, = tf_rbx =3D=20 2152432187, tf_rbp =3D -1270994608, tf_r10 =3D -2139154144, tf_r11 =3D=20 -1270994432, tf_r12 =3D 57, tf_r13 =3D 0, tf_r14 =3D 0, tf_r15 =3D 0, = tf_trapno=20 =3D 12, tf_addr =3D -3413529702, tf_flags =3D -2140901446, tf_err =3D 0, = tf_rip=20 =3D -2142535096, tf_cs =3D 8, tf_rflags =3D 66178, tf_rsp =3D = -1270994848, tf_ss=20 =3D 16}) at /usr/src/sys/amd64/amd64/trap.c:360 #10 0xffffffff80589dfb in calltrap () at=20 /usr/src/sys/amd64/amd64/exception.S:168 #11 0xffffffff8063ca7f in wi_pccard_products () #12 0x0000000000000100 in ?? () #13 0xffffffffb43e2960 in ?? () #14 0xffffffff804b823a in kdebug_mbuf (m0=3D0x0) at=20 /usr/src/sys/netipsec/key_debug.c:670 #15 0xffffffff80442d60 in raw_usend (so=3D0x0, flags=3D0, m=3D0x0, = nam=3D0x0,=20 control=3D0x0, td=3D0x0) at /usr/src/sys/net/raw_usrreq.c:263 #16 0xffffffff804b8d2a in key_send (so=3D0x0, flags=3D0, m=3D0x0, = nam=3D0x0,=20 control=3D0x0, td=3D0x0) at /usr/src/sys/netipsec/keysock.c:532 #17 0xffffffff803fdde4 in sosend (so=3D0xffffff005ef219a0, addr=3D0x0,=20 uio=3D0xffffffffb43e2a80, top=3D0xffffff00608a0e00, control=3D0x0, = flags=3D0, td=3D0xffffff005dda5980) at /usr/src/sys/kern/uipc_socket.c:829 #18 0xffffffff80404d54 in kern_sendit (td=3D0xffffff005dda5980, s=3D4,=20 mp=3D0xffffffffb43e2b50, flags=3D0, control=3D0x0, segflg=3D16) at /usr/src/sys/kern/uipc_syscalls.c:772 #19 0xffffffff80405f16 in sendit (td=3D0xffffff005dda5980, s=3D4,=20 mp=3D0xffffffffb43e2b50, flags=3D0) at = /usr/src/sys/kern/uipc_syscalls.c:712 #20 0xffffffff804062d4 in sendto (td=3D0x0, uap=3D0x0) at=20 /usr/src/sys/kern/uipc_syscalls.c:830 #21 0xffffffff8059cc72 in syscall (frame=3D {tf_rdi =3D 4, tf_rsi =3D 5320768, tf_rdx =3D 16, tf_rcx =3D 0, = tf_r8 =3D 0,=20 tf_r9 =3D 0, tf_rax =3D 133, tf_rbx =3D 5320784, tf_rbp =3D 0, tf_r10 = =3D 4,=20 tf_r11 =3D 5320704, tf_r12 =3D 5320768, tf_r13 =3D 7, tf_r14 =3D 4, = tf_r15 =3D 0,=20 tf_trapno =3D 12, tf_addr =3D 5320704, tf_flags =3D 0, tf_err =3D 2, = tf_rip =3D=20 34367663772, tf_cs =3D 43, tf_rflags =3D 514, tf_rsp =3D = 140737488349848,=20 tf_ss =3D 35}) at /usr/src/sys/amd64/amd64/trap.c:797 #22 0xffffffff80589f98 in Xfast_syscall () at=20 /usr/src/sys/amd64/amd64/exception.S:270 #23 0x0000000000000004 in ?? () #24 0x0000000000513040 in ?? () #25 0x0000000000000010 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000085 in ?? () #30 0x0000000000513050 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000004 in ?? () #33 0x0000000000513000 in ?? () #34 0x0000000000513040 in ?? () #35 0x0000000000000007 in ?? () #36 0x0000000000000004 in ?? () #37 0x0000000000000000 in ?? () #38 0x000000000000000c in ?? () #39 0x0000000000513000 in ?? () #40 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #41 0x0000000000000002 in ?? () #42 0x000000080078ee9c in ?? () #43 0x000000000000002b in ?? () #44 0x0000000000000202 in ?? () #45 0x00007fffffffea98 in ?? () #46 0x0000000000000023 in ?? () #47 0x00007fffffffd4d8 in ?? () #48 0x0000000000000023 in ?? () #49 0x0000000000000000 in ?? () #50 0x0000000000000000 in ?? () #51 0x0000000000000000 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000000 in ?? () #54 0x0000000000000000 in ?? () #55 0x0000000000000000 in ?? () #56 0x0000000000000000 in ?? () #57 0x000000005f9ba000 in ?? () #58 0x0000000000000001 in ?? () #59 0x0000000000000000 in ?? () #60 0xffffff005e4aa9c0 in ?? () #61 0xffffff007b9b74c0 in ?? () #62 0xffffffffb43e2260 in ?? () #63 0xffffffffb43e2238 in ?? () #64 0xffffff005dda5980 in ?? () #65 0xffffffff803cd10a in sched_switch (td=3D0x513050, newtd=3D0x513040, = flags=3D4) at /usr/src/sys/kern/sched_4bsd.c:973 Previous frame inner to this frame (corrupt stack?) Here is my dmesg for the Dell 1850 Copyright (c) 1992-2005 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 6.0-BETA4 #0: Fri Sep 16 01:52:30 UTC 2005 root@tank:/usr/obj/usr/src/sys/GENERIC_IPSEC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.22-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf43 Stepping =3D 3 =20 Features=3D0xbfebfbff Features2=3D0x641d> AMD Features=3D0x20100800 Hyperthreading: 2 logical CPUs real memory =3D 2147221504 (2047 MB) avail memory =3D 2062241792 (1966 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic1: Changing APIC ID to 3 ioapic1: WARNING: intbase 32 !=3D expected base 24 ioapic2: Changing APIC ID to 4 ioapic2: WARNING: intbase 64 !=3D expected base 56 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 3 on acpi0 pci_link2: irq 7 on acpi0 pci_link3: irq 10 on acpi0 pci_link4: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: irq 5 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem=20 0xd80f0000-0xd80fffff,0xdfde0000-0xdfdfffff irq 46 at device 14.0 on = pci2 amr0: Firmware 521S, BIOS H430, 256MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 0.0 on pci4 pci5: on pcib5 em0: port=20 0xecc0-0xecff mem 0xdfae0000-0xdfafffff irq 16 at device 4.0 on pci5 em0: Ethernet address: 00:0e:0c:73:d4:f2 em0: Speed:N/A Duplex:N/A em1: port=20 0xec80-0xecbf mem 0xdfac0000-0xdfadffff irq 17 at device 4.1 on pci5 em1: Ethernet address: 00:0e:0c:73:d4:f3 em1: Speed:N/A Duplex:N/A pcib6: at device 0.2 on pci4 pci6: on pcib6 pcib7: at device 5.0 on pci0 pci7: on pcib7 pcib8: at device 0.0 on pci7 pci8: on pcib8 em2: port=20 0xdcc0-0xdcff mem 0xdf7e0000-0xdf7fffff irq 64 at device 7.0 on pci8 em2: Ethernet address: 00:14:22:15:ff:4b em2: Speed:N/A Duplex:N/A pcib9: at device 0.2 on pci7 pci9: on pcib9 em3: port=20 0xccc0-0xccff mem 0xdf5e0000-0xdf5fffff irq 65 at device 8.0 on pci9 em3: Ethernet address: 00:14:22:15:ff:4c em3: Speed:N/A Duplex:N/A pcib10: at device 6.0 on pci0 pci10: on pcib10 uhci0: port 0xace0-0xacff=20 irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xacc0-0xacdf=20 irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xaca0-0xacbf=20 irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xdff00000-0xdff003ff irq = 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 uhub4: multiple transaction translators uhub4: 2 ports with 2 removable, self powered pcib11: at device 30.0 on pci0 pci11: on pcib11 pci11: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port=20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on = acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on=20 acpi0 sio0: type 16550A, console orm0: at iomem=20 0xc0000-0xcafff,0xcb000-0xcbfff,0xce800-0xcf7ff,0xec000-0xeffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x100> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, = addr 2 Timecounters tick every 1.000 msec Fast IPsec: Initialized Security Association Processing. acd0: DVDROM at ata0-master UDMA33 amrd0: on amr0 amrd0: 139900MB (286515200 sectors) RAID 1 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/amrd0s1a WARNING: / was not properly dismounted em2: link state changed to UP em3: link state changed to UP Cheers, Mike ------------------------------ _______________________________________________ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" End of freebsd-amd64 Digest, Vol 119, Issue 5 ********************************************* ------_=_NextPart_001_01C5BB05.6BD48F3A--