From owner-freebsd-amd64@FreeBSD.ORG Sun Nov 30 20:10:57 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12E1D1065672; Sun, 30 Nov 2008 20:10:56 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id ABAB78FC08; Sun, 30 Nov 2008 20:10:55 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 228427600; Sun, 30 Nov 2008 22:10:54 +0200 Message-ID: <4932F34C.1040804@FreeBSD.org> Date: Sun, 30 Nov 2008 22:10:52 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Jung-uk Kim References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> In-Reply-To: <1224728582.00028075.1224715806@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org, peter@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Sun, 30 Nov 2008 20:10:57 -0000 Hi. Alexander Motin wrote: > Jung-uk Kim wrote: >> I was working on suspend/resume support for amd64 and this is the >> result. It works with a modified QEMU (QEMU does not support S3) but >> real boxes that I have don't seem to like it (e.g., broken BIOSes). >> If there is someone interested in finishing it off or giving it a try, >> the patch is here: >> >> http://people.freebsd.org/~jkim/amd64_suspend.diff > > I have tried it on my Acer TM6292. S1/S2 are unsupported. On S3 system > successfully got down, but on wakeup button, two seconds after power up, > even without video initialization, it shut down, reset and then started > usual boot. I have tried both original and updated BIOS, without any > difference. > > Can I give you any other help? I have spent a day investigating the problem. I was inserting empty infinite loop into the different points of wakeup process trying to find the place where system reboots. I just haven't found any other feedback channel as video is not initialized and beeper is not working for some reason. As result, I have found, that if I am inserting: qqq: jmp qqq lines before line 98 of acpi_switch.S: movl $MSR_MTRRdefType, %ecx movl WAKEUP_CTX(mtrr), %eax wrmsr system hangs, but if I insert it just after them - system reboots. With just commenting this three lines I was able to get successful suspend/resume with UP amd64 kernel!!! Here is problems I still have now: - SMP kernel resume is not working, system reboots while doing acpi_wakeup_cpus(); - SATA controller does not resumes correctly, it dies for some reason, reporting timeouts on any request; - text mode video does not restores on resume, while Xorg graphic one does. hw.acpi.reset_video=1 does not help, it just hanging resume process. -- Alexander Motin From owner-freebsd-amd64@FreeBSD.ORG Sun Nov 30 23:00:07 2008 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 914F710656FD for ; Sun, 30 Nov 2008 23:00:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 659658FC17 for ; Sun, 30 Nov 2008 23:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAUN05HP065172 for ; Sun, 30 Nov 2008 23:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAUN05O4065171; Sun, 30 Nov 2008 23:00:05 GMT (envelope-from gnats) Resent-Date: Sun, 30 Nov 2008 23:00:05 GMT Resent-Message-Id: <200811302300.mAUN05O4065171@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Robert Brown Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 424191065676 for ; Sun, 30 Nov 2008 22:56:23 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 304B18FC18 for ; Sun, 30 Nov 2008 22:56:23 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mAUMuNHD040039 for ; Sun, 30 Nov 2008 22:56:23 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id mAUMuMog040038; Sun, 30 Nov 2008 22:56:22 GMT (envelope-from nobody) Message-Id: <200811302256.mAUMuMog040038@www.freebsd.org> Date: Sun, 30 Nov 2008 22:56:22 GMT From: Robert Brown To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Mon, 01 Dec 2008 00:20:13 +0000 Cc: Subject: amd64/129315: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 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: Sun, 30 Nov 2008 23:00:07 -0000 >Number: 129315 >Category: amd64 >Synopsis: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 30 23:00:05 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Robert Brown >Release: 8.0-CURRENT >Organization: None >Environment: N/A - Kernel will not boot >Description: On the Intel DG965WH motherboard, FreeBSD will not boot. I am using the Intel DG965WH motherboard as described here: http://download.intel.com/support/motherboards/desktop/dg965wh/sb/d5600801us.pdf http://www.intel.com/products/desktop/motherboards/dg965wh/dg965wh-overview.htm The kernel does not panic; the system simply gets to the same point during an initial bootup and then reboots as if the 'reset' button on the front of the machine was pressed. Generally this happens after the 'em0' device is initialized but before any disks are detected or mounted. This behavior is consistent with 6.3-RELEASE, 6.4-RELEASE, 7.0-RELEASE, and 7.1-BETA2 using the bootonly installation ISOs. There is an interesting difference using the 200811 snapshot ISO for FreeBSD 8. On this kernel bootup, it does not just reset the computer but hangs/freezes during the boot. The good news is that I am able to capture the output at the point that it freezes: -- BEGIN CAPTURED OUTPUT -- pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found -> vendor=0x8086, dev=0x29a0, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found -> vendor=0x8086, dev=0x29a2, revid=0x02 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xd0200000, size 20, enabled -- END CAPTURED OUTPUT -- At that point it just stops booting and sits there. The machine must be physically reset. OK, so this tells me that it could have something to do with the PCI bus and/or disk controller. To troubleshoot, I first made sure I was on the latest BIOS release 1754, which is the latest release as of 11/08. Next, I went into the BIOS configuration and configured it as follows. The idea was to disable everything possible to narrow down the cause. Advanced -> Boot Configuration: -- Numlock: On -- Max CPUID Value Limit: Disable -- Display Setup Prompt: On Advanced -> Peripheral Configuration: -- Serial Port: Disable -- Parallel Port: Disable -- Audio: Disable -- On-board LAN: Disable -- Onboard 1394: Disable Advanced -> Drive Configuration: -- ATA/IDE Mode: Legacy (Other option is 'Native') -- S.M.A.R.T.: Enable -- Hard Disk Pre-Delay: No NOTE: Changing ATA/IDE mode to "Native" allows another option, which is "Configure SATA As" with three choices - IDE, RAID, and AHCI. I have tried with every combination as follows: 1) Legacy - Produces errors as described above 2) Native, IDE - Hangs after pcib0 and pci0 lines, no 'found' lines 3) Native, RAID - Produces errors as described above 4) Native, AHCI - Produces errors as described above Advanced -> Floppy Configuration: Advanced -> Video Configuration: -- DVMT Mode: DVMT -- IGD DVMT Memory: 128mb -- IGD Aperture Size: 256mb -- Primary Video Adaptor: auto Advanced -> Chipset Configuration -> Memory Configuration -- SDRAM Control: Automatic (800Mhz, 5.0-5-5-18) Advanced -> Chipset Configuration -- PCI Latency Timer: 32 -- HPET: Enable Advanced -> USB Configuration -- USB Ports: Disable That's it for the relevant BIOS settings. Note that there are no USB or Firewire devices connected and there are no PCI or other cards of any sort plugged in to this system. It is the motherboard, CPU, RAM, a single ATA100 hard drive of type ST3160812A, and a DVD-ROM of type HL-DT-STDVD-ROM. This same system can and does run Fedora Linux. There are a few special boot options that are required to boot Linux properly, as described in this link: http://www.gvenkat.com/archives/2007/08/09/gentoo-linux-20070-intel-dg965wh-and-ide-cddvd-drives/ Specifically, the Linux kernel wants the options "all-generic-ide pci=nommconf" which I am not very familiar with. The same problems of rebooting on kernel boot happened with Linux until those options were passed to the kernel. Under Linux, it appears that the pci=nommconf boot option tells the kernel not to probe the PCI hardware. I am wondering if there is something similar for FreeBSD. >How-To-Repeat: Boot the install media for any FreeBSD release, 6.3, 6.4, 7.0, 7.1-BETA2, or the 200811 snapshot of FreeBSD 8. >Fix: None at this time. I expect that there may be some special kernel boot option similar to what is required on Linux. I can capture any and all debugging information requested for this issue as well. Let me know what is needed and I'm happy to help. Suggestions, comments, or questions are welcome. Thanks! >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 1 01:42:45 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCAAC106564A; Mon, 1 Dec 2008 01:42:45 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id A560E8FC18; Mon, 1 Dec 2008 01:42:44 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 228437440; Mon, 01 Dec 2008 03:42:43 +0200 Message-ID: <49334110.4010308@FreeBSD.org> Date: Mon, 01 Dec 2008 03:42:40 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Jung-uk Kim References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> In-Reply-To: <4932F34C.1040804@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org, peter@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Mon, 01 Dec 2008 01:42:45 -0000 Alexander Motin wrote: > As result, I have found, that if I am inserting: > qqq: > jmp qqq > lines before line 98 of acpi_switch.S: > movl $MSR_MTRRdefType, %ecx > movl WAKEUP_CTX(mtrr), %eax > wrmsr > system hangs, but if I insert it just after them - system reboots. > > With just commenting this three lines I was able to get successful > suspend/resume with UP amd64 kernel!!! > > Here is problems I still have now: > - SMP kernel resume is not working, system reboots while doing > acpi_wakeup_cpus(); > - SATA controller does not resumes correctly, it dies for some reason, > reporting timeouts on any request; This one is not a problem anymore. Seems to be fixed. > - text mode video does not restores on resume, while Xorg graphic one > does. hw.acpi.reset_video=1 does not help, it just hanging resume process. -- Alexander Motin From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 1 04:50:04 2008 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354571065673 for ; Mon, 1 Dec 2008 04:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2504A8FC12 for ; Mon, 1 Dec 2008 04:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB14o3H7027193 for ; Mon, 1 Dec 2008 04:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB14o3qO027192; Mon, 1 Dec 2008 04:50:03 GMT (envelope-from gnats) Date: Mon, 1 Dec 2008 04:50:03 GMT Message-Id: <200812010450.mB14o3qO027192@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Bruce Albrecht Cc: Subject: Re: amd64/129315: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Albrecht List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 04:50:04 -0000 The following reply was made to PR amd64/129315; it has been noted by GNATS. From: Bruce Albrecht To: Robert Brown Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: amd64/129315: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 Date: Sun, 30 Nov 2008 22:28:09 -0600 Robert Brown wrote: >> Number: 129315 >> Category: amd64 >> Synopsis: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 >> Confidential: no >> Severity: serious >> Priority: medium >> Responsible: freebsd-amd64 >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Sun Nov 30 23:00:05 UTC 2008 >> Closed-Date: >> Last-Modified: >> Originator: Robert Brown >> Release: 8.0-CURRENT >> Organization: > None >> Environment: > N/A - Kernel will not boot >> Description: > On the Intel DG965WH motherboard, FreeBSD will not boot. I am using the Intel DG965WH motherboard as described here: > http://download.intel.com/support/motherboards/desktop/dg965wh/sb/d5600801us.pdf > http://www.intel.com/products/desktop/motherboards/dg965wh/dg965wh-overview.htm > > The kernel does not panic; the system simply gets to the same point during an initial bootup and then reboots as if the 'reset' button on the front of the machine was pressed. Generally this happens after the 'em0' device is initialized but before any disks are detected or mounted. This behavior is consistent with 6.3-RELEASE, 6.4-RELEASE, 7.0-RELEASE, and 7.1-BETA2 using the bootonly installation ISOs. > > There is an interesting difference using the 200811 snapshot ISO for FreeBSD 8. On this kernel bootup, it does not just reset the computer but hangs/freezes during the boot. The good news is that I am able to capture the output at the point that it freezes: > > -- BEGIN CAPTURED OUTPUT -- > > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found -> vendor=0x8086, dev=0x29a0, revid=0x02 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found -> vendor=0x8086, dev=0x29a2, revid=0x02 > domain=0, bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range 32, base 0xd0200000, size 20, enabled > > -- END CAPTURED OUTPUT -- > > At that point it just stops booting and sits there. The machine must be physically reset. > > OK, so this tells me that it could have something to do with the PCI bus and/or disk controller. To troubleshoot, I first made sure I was on the latest BIOS release 1754, which is the latest release as of 11/08. Next, I went into the BIOS configuration and configured it as follows. The idea was to disable everything possible to narrow down the cause. > > Advanced -> Boot Configuration: > -- Numlock: On > -- Max CPUID Value Limit: Disable > -- Display Setup Prompt: On > > Advanced -> Peripheral Configuration: > -- Serial Port: Disable > -- Parallel Port: Disable > -- Audio: Disable > -- On-board LAN: Disable > -- Onboard 1394: Disable > > Advanced -> Drive Configuration: > -- ATA/IDE Mode: Legacy (Other option is 'Native') > -- S.M.A.R.T.: Enable > -- Hard Disk Pre-Delay: No > > NOTE: Changing ATA/IDE mode to "Native" allows another option, which is "Configure SATA As" with three choices - IDE, RAID, and AHCI. I have tried with every combination as follows: > > 1) Legacy - Produces errors as described above > 2) Native, IDE - Hangs after pcib0 and pci0 lines, no 'found' lines > 3) Native, RAID - Produces errors as described above > 4) Native, AHCI - Produces errors as described above > > Advanced -> Floppy Configuration: > > > Advanced -> Video Configuration: > -- DVMT Mode: DVMT > -- IGD DVMT Memory: 128mb > -- IGD Aperture Size: 256mb > -- Primary Video Adaptor: auto > > Advanced -> Chipset Configuration -> Memory Configuration > -- SDRAM Control: Automatic (800Mhz, 5.0-5-5-18) > > Advanced -> Chipset Configuration > -- PCI Latency Timer: 32 > -- HPET: Enable > > Advanced -> USB Configuration > -- USB Ports: Disable > > > That's it for the relevant BIOS settings. Note that there are no USB or Firewire devices connected and there are no PCI or other cards of any sort plugged in to this system. It is the motherboard, CPU, RAM, a single ATA100 hard drive of type ST3160812A, and a DVD-ROM of type HL-DT-STDVD-ROM. > > This same system can and does run Fedora Linux. There are a few special boot options that are required to boot Linux properly, as described in this link: > http://www.gvenkat.com/archives/2007/08/09/gentoo-linux-20070-intel-dg965wh-and-ide-cddvd-drives/ > > Specifically, the Linux kernel wants the options "all-generic-ide pci=nommconf" which I am not very familiar with. The same problems of rebooting on kernel boot happened with Linux until those options were passed to the kernel. > > Under Linux, it appears that the pci=nommconf boot option tells the kernel not to probe the PCI hardware. I am wondering if there is something similar for FreeBSD. > >> How-To-Repeat: > Boot the install media for any FreeBSD release, 6.3, 6.4, 7.0, 7.1-BETA2, or the 200811 snapshot of FreeBSD 8. >> Fix: > None at this time. I expect that there may be some special kernel boot option similar to what is required on Linux. > > I can capture any and all debugging information requested for this issue as well. Let me know what is needed and I'm happy to help. > > Suggestions, comments, or questions are welcome. Thanks! How much memory is installed on this machine? I have one of these motherboards, with a Core 2 Quad Q6600 and 4 GB memory. Mine has an older BIOS (I think from about a year ago), but at the time there was a bug in the BIOS that caused it to return bad values so that the memory over 4GB was misclassified. Linux users were able to manually reclassify the memory, but I never got it working on FreeBSD. If you are running with more than 4GB memory, what happens if you remove memory, or add hw.physmem="4G" to /boot/loader.conf? Here's a link to a message thread to my problem with this board: http://groups.google.com/group/lucky.freebsd.current/browse_thread/thread/92fd4e9ef6f2b5bb From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 1 04:51:51 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9D7D106564A; Mon, 1 Dec 2008 04:51:51 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA7E8FC22; Mon, 1 Dec 2008 04:51:51 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mB14GOja054545; Mon, 1 Dec 2008 15:16:24 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 1 Dec 2008 15:16:24 +1100 (EST) From: Ian Smith To: Alexander Motin In-Reply-To: <49334110.4010308@FreeBSD.org> Message-ID: <20081201150743.V34249@sola.nimnet.asn.au> References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <49334110.4010308@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 01 Dec 2008 05:17:37 +0000 Cc: peter@freebsd.org, freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Mon, 01 Dec 2008 04:51:51 -0000 On Mon, 1 Dec 2008, Alexander Motin wrote: > Alexander Motin wrote: > > As result, I have found, that if I am inserting: > > qqq: > > jmp qqq > > lines before line 98 of acpi_switch.S: > > movl $MSR_MTRRdefType, %ecx > > movl WAKEUP_CTX(mtrr), %eax > > wrmsr > > system hangs, but if I insert it just after them - system reboots. > > > > With just commenting this three lines I was able to get successful > > suspend/resume with UP amd64 kernel!!! > > > > Here is problems I still have now: > > - SMP kernel resume is not working, system reboots while doing > > acpi_wakeup_cpus(); > > - SATA controller does not resumes correctly, it dies for some reason, > > reporting timeouts on any request; > > This one is not a problem anymore. Seems to be fixed. Progress! > > - text mode video does not restores on resume, while Xorg graphic one > > does. hw.acpi.reset_video=1 does not help, it just hanging resume process. Longshot: hw.syscons.sc_no_suspend_vtswitch=1 fixes similar symptoms on two (older, i386 and UP) laptops here. Some folks have reported needing to have VESA loaded to get text mode video back up. Maybe worth a try? cheers, Ian From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 1 05:30:05 2008 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54AD31065670 for ; Mon, 1 Dec 2008 05:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 445518FC17 for ; Mon, 1 Dec 2008 05:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB15U5bN062324 for ; Mon, 1 Dec 2008 05:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB15U5lr062319; Mon, 1 Dec 2008 05:30:05 GMT (envelope-from gnats) Date: Mon, 1 Dec 2008 05:30:05 GMT Message-Id: <200812010530.mB15U5lr062319@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: "Robert J. Brown" X-Mailman-Approved-At: Mon, 01 Dec 2008 12:18:25 +0000 Cc: Subject: Re: amd64/129315: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Robert J. Brown" List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 05:30:05 -0000 The following reply was made to PR amd64/129315; it has been noted by GNATS. From: "Robert J. Brown" To: bug-followup@FreeBSD.org, rjb@robertjbrown.com Cc: Subject: Re: amd64/129315: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 Date: Sun, 30 Nov 2008 20:58:14 -0800 --Apple-Mail-2-692191080 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable I have another weird problem as part of this. If I boot the 7.1-BETA2 =20= or 8.0 snapshot 200811 bootonly iso images and hit 6 to escape to the =20= prompt, I can type for about 1-3 seconds and the system freezes. No =20 more characters can be input and this is consistent across all boots =20 of the ISOs. When I move back to the 7.0-RELEASE ISO, both bootonly =20 and disc1, they allow me to hit 6 to escape to the prompt and I can =20 type as long as I like with no lockups whatsoever. On a 7.0-RELEASE CD, I hit 6 to get to the boot prompt and asked it =20 for my settings. Here's what it has, manually typed by me. For this =20 capture I had re-enabled serial, parallel, network, firewire, and USB =20= ports. LINES=3D24 acpi_load=3DYES autoboot_delay=3DNO bootfile=3Dkernel comconsole_speed=3D9600 console=3Dvidconsole currdev=3Dcd0: hint.acpi.0.oem=3DINTEL hint.acpi.0.revision=3D1 hint.acpi.0.rsdp=3D0xfe020 hint.acpi.0.rsdt=3D0xbe6fd038 hint.atkbd.0.at=3Datkbdc hint.atkbd.0.irq=3D1 hint.atkbdc.0.at=3Disa hint.atkbdc.0.port=3D0x060 hint.fd.0.at=3Dfdc0 hint.fc.0.drive=3D0 hint.fd.1.at=3Dfdc0 hint.fd.1.drive=3D1 hint.fdc.0.at=3Disa hint.fdc.0.drq=3D2 hint.fdc.0.irq=3D6 hint.fdc.0.port=3D0x3F0 hint.ppc.0.at=3Disa hint.ppc.0.irq=3D7 hint.psm.0.at=3Datkbdc hint.psm.0.irq=3D12 hint.sc.0.at=3Disa hint.sc.0.flags=3D0x100 hint.sio.0.at=3Disa hint.sio.0.flags=3D0x10 hint.sio.0.irq=3D4 hint.sio.0.port=3D0x3F8 hint.sio.1.at=3Disa hint.sio.1.irq=3D3 hint.sio.1.port=3D0x2F8 hint.sio.2.at=3Disa hint.sio.2.disabled=3D1 hint.sio.2.irq=3D5 hint.sio.2.port=3D0x3E8 hint.sio.3.at=3Disa hint.sio.3.disabled=3D1 hint.sio.3.irq=3D9 hint.sio.3.port=3D0x2E8 hint.vga.0.at=3Disa interpret=3DOK kernel=3Dkernel kernel_options=3D kernelname=3D/boot/kernel/kernel loaddev=3Dcd0: mac_ifoff=3DNO module_path=3D/boot/kernel;/boot/modules prompt=3D${interpret} smbios.bios.reldate=3D11/17/2008 smbios.bios.vendor=3DIntel Corp. smbios.bios.version=3DMQ96510J.86A.1754.2008.1117.0002 smbios.chassis.maker=3D smbios.chassis.serial=3D smbios.chassis.tag=3D smbios.chassis.version=3D smbios.planar.maker=3DIntel Corporation smbios.planar.product=3DDG965WH smbios.planar.serial=3DBQWH6380064A smbios.planar.version=3DAAD41692-304 smbios.socket.enabled=3D1 smbios.socket.populated=3D1 smbios.system.maker=3D smbios.system.product=3D smbios.system.serial=3D smbios.system.uuid=3Daafeeac0-4d35-11db-9304-00e01888972e smbios.system.version=3D More information from the Intel technical spec for this board: 1.5.3.1 Serial ATA Support The ICH8=92s Serial ATA controller offers six independent Serial ATA =20 ports with a theoretical maximum transfer rate of 3 Gbits/sec per port. One device =20= can be installed on each port for a maximum of six Serial ATA devices. A point-to-=20 point interface is used for host to device connections, unlike Parallel ATA IDE which =20 supports a master/slave configuration and two devices per channel. For compatibility, the underlying Serial ATA functionality is =20 transparent to the operating system. The Serial ATA controller can operate in both =20 legacy and native modes. In legacy mode, standard IDE I/O and IRQ resources are =20 assigned (IRQ 14 and 15). In Native mode, standard PCI Conventional bus resource =20 steering is used. Native mode is the preferred mode for configurations using the =20 Windows* XP and Windows 2000 operating systems. --Apple-Mail-2-692191080 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
I have another weird = problem as part of this. If I boot the 7.1-BETA2 or 8.0 snapshot 200811 = bootonly iso images and hit 6 to escape to the prompt, I can type for = about 1-3 seconds and the system freezes. No more characters can be = input and this is consistent across all boots of the ISOs. When I move = back to the 7.0-RELEASE ISO, both bootonly and disc1, they allow me to = hit 6 to escape to the prompt and I can type as long as I like with no = lockups whatsoever. 

On a 7.0-RELEASE CD, = I hit 6 to get to the boot prompt and asked it for my settings. Here's = what it has, manually typed by me. For this capture I had re-enabled = serial, parallel, network, firewire, and USB = ports. 

LINES=3D24
autoboot_delay=3DNO
comconsole_speed=3D9600
currdev=3Dcd0:
hint.acpi.0.revision=3D1
hint.atkbd.0.at=3Datkbdc
hint.atkbdc.0.at=3Disa
hint.fd.0.at=3Dfdc0
hint.fd.1.at=3Dfdc0
hint.fdc.0.at=3Disa
hint.fdc.0.irq=3D6
hint.ppc.0.at=3Disa
hint.psm.0.at=3Datkbdc
hint.sc.0.at=3Disa
hint.sio.0.at=3Disa
hint.sio.0.irq=3D4
hint.sio.1.at=3Disa
hint.sio.1.port=3D0x2F8
hint.sio.2.disabled=3D1
hint.sio.2.port=3D0x3E8
hint.sio.3.disabled=3D1
hint.sio.3.port=3D0x2E8
interpret=3DOK
kernel=3Dkernel
kernelname=3D/boot/kernel/kernel
mac_ifoff=3DNO
smbios.bios.vendor=3DIntel = Corp.
smbios.chassis.serial=3D
smbios.chassis.version=3D
smbios.system.maker=3D
smbios.system.serial=3D
= Serial ATA Support 
The ICH8=92s Serial ATA = controller offers six independent Serial ATA ports with = a 
theoretical maximum transfer rate of 3 Gbits/sec = per port.  One device can be installed 
on = each port for a maximum of six Serial ATA devices.  A = point-to-point interface is 
used for host to device = connections, unlike Parallel ATA IDE which supports a 
For compatibility, the underlying Serial ATA = functionality is transparent to the 
operating system.  The = Serial ATA controller can operate in both legacy and = native 
modes.  In legacy mode, standard IDE I/O and = IRQ resources are assigned (IRQ 14 
and 15).  In Native = mode, standard PCI Conventional bus resource steering is used. =  
Native mode is the preferred mode for = configurations using the Windows* XP and 



= = --Apple-Mail-2-692191080-- From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 1 06:40:04 2008 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66B531065673 for ; Mon, 1 Dec 2008 06:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 585878FC17 for ; Mon, 1 Dec 2008 06:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB16e39I019430 for ; Mon, 1 Dec 2008 06:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB16e34S019429; Mon, 1 Dec 2008 06:40:03 GMT (envelope-from gnats) Date: Mon, 1 Dec 2008 06:40:03 GMT Message-Id: <200812010640.mB16e34S019429@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: "Robert J. Brown" X-Mailman-Approved-At: Mon, 01 Dec 2008 12:24:27 +0000 Cc: Subject: Re: amd64/129315: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Robert J. Brown" List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 06:40:04 -0000 The following reply was made to PR amd64/129315; it has been noted by GNATS. From: "Robert J. Brown" To: Bruce Albrecht Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: amd64/129315: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 Date: Sun, 30 Nov 2008 22:05:13 -0800 On Nov 30, 2008, at 8:28 PM, Bruce Albrecht wrote: >> > > How much memory is installed on this machine? I have one of these > motherboards, with a Core 2 Quad Q6600 and 4 GB memory. Mine has an > older BIOS (I think from about a year ago), but at the time there > was a bug in the BIOS that caused it to return bad values so that > the memory over 4GB was misclassified. Linux users were able to > manually reclassify the memory, but I never got it working on > FreeBSD. If you are running with more than 4GB memory, what happens > if you remove memory, or add > > hw.physmem="4G" > > to /boot/loader.conf? > > Here's a link to a message thread to my problem with this board: > http://groups.google.com/group/lucky.freebsd.current/browse_thread/thread/92fd4e9ef6f2b5bb > Bruce, Thanks for the reply. This system has 3GB of memory, 2 banks of matched 512MB and 2 banks of matched 1GB. I saw the BIOS weirdness about the 4GB issue but since I have less than that amount I didn't pay much attention to it. Thanks for the link - I will check that out as well. For now I am trying various combinations of BIOS settings for the disk controller combined with set hint.apic.0.disabled="1", unset acpi_load, and set hint.acpi.0.disabled="1". Disabling ACPI causes a freeze instead of a complete reboot, which is progress. There are lots of messages about not properly allocating IRQs which I find strange. The system on 7.0-RELEASE with ACPI/APIC disabled hangs when trying to mount the image to continue the installation. Do you have FreeBSD 7.X / amd64 running on this board? If yes, can you provide your exact BIOS release? I'll downgrade to that and see if it helps. Thanks, -Robert -- Robert J. Brown rjb@robertjbrown.com From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 1 08:40:03 2008 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77C291065678 for ; Mon, 1 Dec 2008 08:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6936B8FC1D for ; Mon, 1 Dec 2008 08:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB18e31Q037820 for ; Mon, 1 Dec 2008 08:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB18e30K037818; Mon, 1 Dec 2008 08:40:03 GMT (envelope-from gnats) Date: Mon, 1 Dec 2008 08:40:03 GMT Message-Id: <200812010840.mB18e30K037818@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: "Robert J. Brown" X-Mailman-Approved-At: Mon, 01 Dec 2008 12:24:42 +0000 Cc: Subject: Re: amd64/129315: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Robert J. Brown" List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 08:40:03 -0000 The following reply was made to PR amd64/129315; it has been noted by GNATS. From: "Robert J. Brown" To: bug-followup@FreeBSD.org, rjb@robertjbrown.com Cc: Subject: Re: amd64/129315: amd64 motherboard: Intel DG965WH motherboard compatibility with AMD64 Date: Mon, 1 Dec 2008 00:33:57 -0800 I have since tried a few things: -- Removed memory down to 1GB (matched pair of 512mb modules, dual channel mode - channel A DIMM0, channel B DIMM0) -- Backed the BIOS down to earlier revisions due to other reports of bug issues with newer BIOSes. I tried 1754, 1716, 1705, 1699, and 1669. The 1669 BIOS was supposed to fix some bugs introduced in later revisions but my system behaves exactly the same. With 7.0-RELEASE, option 1 on the install CD still does a clean reboot about half way through kernel initialization. Option 2 to disable ACPI gets further and then hangs while trying to mount root from ufs:/dev/ md0. This requires a manual reboot. Here is what I can see of the screen as it is frozen from option #2. This was manually typed in. -- BEGIN SCREEN CAPTURE -- device_attach: atapci1 attach returned 6 pci0: at device 31.3 (no driver attached) orm0: at iomem 0xcb800-0xcd7ff, 0xcd800-0xce7ff, 0xce800-0xcf7ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 fdc0: cannot reserve interrupt line ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A 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 RTC BIOS diagnostic error 80 Timecounter "TSC" frequency 1872271506 Hz quality 800 Timecounters ticket every 1.000 msec hptrr: no controller detected md0: Preloaded image 4194304 bytes at 0xffffffff80bc6c08 Trying to mount root from ufs:/dev/md0 -- END SCREEN CAPTURE -- My next step is to re-roll the latest CVSUP'd sources from the 7.1 tree into a make release on a different (working) amd64 system. I'd like to see what the latest source will get me but I'm not optimistic at this point. Question: should I try the i386 build to see if there are any differences? I really need to run amd64 but I am open to trying i386 if it would help get to the bottom of this. From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 1 11:06:51 2008 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4AE41065677 for ; Mon, 1 Dec 2008 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C005E8FC19 for ; Mon, 1 Dec 2008 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB1B6p8Z052472 for ; Mon, 1 Dec 2008 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB1B6pCh052468 for freebsd-amd64@FreeBSD.org; Mon, 1 Dec 2008 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Dec 2008 11:06:51 GMT Message-Id: <200812011106.mB1B6pCh052468@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-amd64@FreeBSD.org X-Mailman-Approved-At: Mon, 01 Dec 2008 12:24:59 +0000 Cc: Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org 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: Mon, 01 Dec 2008 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/129315 amd64 amd64 motherboard: Intel DG965WH motherboard compatibi o amd64/129238 amd64 [panic] System randomly panics f amd64/128978 amd64 [install] FreeBSD 6.3 64-bit panics at boot time duri o amd64/128810 amd64 AMD 64 port installation o amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/128686 amd64 [ata] can't detect SATA Disk on 8.0-Current with NF550 o amd64/128524 amd64 No geom documentation for loading gjournal o amd64/128263 amd64 [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 a o amd64/128259 amd64 csh(1): "`" crashes csh o amd64/128236 amd64 portsdb -Uu Indexing error f kern/128102 amd64 AsusRock 939N68PV-GLAN not recognized o amd64/127787 amd64 [lor] 3 lock LOR in recent CURRENT o amd64/127640 amd64 GCC will not build shared libraries with -fprofile-gen o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 f amd64/125943 amd64 Serial Consoles do not work on amd64 freebsd o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119936 amd64 [install] FreeBSD 7.0-RC1 amd64 and i386 installer dis o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V f amd64/116670 amd64 [ata] onboard SATA RAID1 controllers not supported for o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on f amd64/116457 amd64 [install] can't install freebsd on dv9420us o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff f amd64/91492 amd64 [boot] BTX halted o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not o amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 86 problems total. From owner-freebsd-amd64@FreeBSD.ORG Mon Dec 1 17:19:36 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C85331065672; Mon, 1 Dec 2008 17:19:36 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 98B0A8FC0A; Mon, 1 Dec 2008 17:19:35 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 228495667; Mon, 01 Dec 2008 19:19:34 +0200 Message-ID: <49341CA4.8060801@FreeBSD.org> Date: Mon, 01 Dec 2008 19:19:32 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Ian Smith References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <49334110.4010308@FreeBSD.org> <20081201150743.V34249@sola.nimnet.asn.au> In-Reply-To: <20081201150743.V34249@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: peter@freebsd.org, freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Mon, 01 Dec 2008 17:19:36 -0000 Ian Smith wrote: > On Mon, 1 Dec 2008, Alexander Motin wrote: > > Alexander Motin wrote: > > > As result, I have found, that if I am inserting: > > > qqq: > > > jmp qqq > > > lines before line 98 of acpi_switch.S: > > > movl $MSR_MTRRdefType, %ecx > > > movl WAKEUP_CTX(mtrr), %eax > > > wrmsr > > > system hangs, but if I insert it just after them - system reboots. > > > > > > With just commenting this three lines I was able to get successful > > > suspend/resume with UP amd64 kernel!!! > > > > > > Here is problems I still have now: > > > - SMP kernel resume is not working, system reboots while doing > > > acpi_wakeup_cpus(); > > > - SATA controller does not resumes correctly, it dies for some reason, > > > reporting timeouts on any request; > > > > This one is not a problem anymore. Seems to be fixed. > > Progress! > > > > - text mode video does not restores on resume, while Xorg graphic one > > > does. hw.acpi.reset_video=1 does not help, it just hanging resume process. > > Longshot: hw.syscons.sc_no_suspend_vtswitch=1 fixes similar symptoms on > two (older, i386 and UP) laptops here. Some folks have reported needing > to have VESA loaded to get text mode video back up. Maybe worth a try? vtswitch does not help and vesa generally does not working under amd64. -- Alexander Motin From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 10:16:43 2008 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B4EF1065687; Tue, 2 Dec 2008 10:16:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 26E718FC16; Tue, 2 Dec 2008 10:16:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB2AGdqU023480; Tue, 2 Dec 2008 05:16:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB2AGdNk041779; Tue, 2 Dec 2008 05:16:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 93F7773039; Tue, 2 Dec 2008 05:16:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081202101639.93F7773039@freebsd-current.sentex.ca> Date: Tue, 2 Dec 2008 05:16:39 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2008 10:16:43 -0000 TB --- 2008-12-02 09:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 09:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-12-02 09:00:00 - cleaning the object tree TB --- 2008-12-02 09:00:53 - cvsupping the source tree TB --- 2008-12-02 09:00:53 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-12-02 09:01:00 - building world TB --- 2008-12-02 09:01:00 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 09:01:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 09:01:00 - TARGET=amd64 TB --- 2008-12-02 09:01:00 - TARGET_ARCH=amd64 TB --- 2008-12-02 09:01:00 - TZ=UTC TB --- 2008-12-02 09:01:00 - __MAKE_CONF=/dev/null TB --- 2008-12-02 09:01:00 - cd /src TB --- 2008-12-02 09:01:00 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 09:01:02 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_basic.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_bin.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_cred.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_files.c: In function 'procstat_files': /src/usr.bin/procstat/procstat_files.c:272: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 10:16:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 10:16:39 - ERROR: failed to build world TB --- 2008-12-02 10:16:39 - 3596.12 user 362.23 system 4598.56 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 09:20:03 2008 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 718471065672 for ; Tue, 2 Dec 2008 09:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 69D528FC12 for ; Tue, 2 Dec 2008 09:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB29K3L8098099 for ; Tue, 2 Dec 2008 09:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB29K3ox098098; Tue, 2 Dec 2008 09:20:03 GMT (envelope-from gnats) Date: Tue, 2 Dec 2008 09:20:03 GMT Message-Id: <200812020920.mB29K3ox098098@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: "Jurriaan Nijkamp" X-Mailman-Approved-At: Tue, 02 Dec 2008 12:24:39 +0000 Cc: Subject: Re: amd64/129238: [panic] System randomly panics X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jurriaan Nijkamp List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2008 09:20:03 -0000 The following reply was made to PR amd64/129238; it has been noted by GNATS. From: "Jurriaan Nijkamp" To: bug-followup@FreeBSD.org, alias@jurrie.net Cc: Subject: Re: amd64/129238: [panic] System randomly panics Date: Tue, 2 Dec 2008 08:13:22 +0100 (CET) After another crash yesterday, I got a new dump which, according to someone who knows what he's talking about, is actually useful. He also said the problem may lie with faulty memory, but I must say I did a memtest86+ test last week which said my memory was working perfectly. I am pasting the output of kgdb below. ---- output of kgdb kernel.debug /var/crash/vmcore.9 ---- [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Unde fined 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 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: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffff800004003908 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff8072436c stack pointer = 0x10:0xffffffffae6d2a00 frame pointer = 0x10:0x4000000000 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 5551 (sed) trap number = 12 panic: page fault cpuid = 0 Uptime: 4h42m45s Physical memory: 2035 MB Dumping 311 MB: 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 #0 doadump () at pcpu.h:194 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:194 #1 0x0000000000000004 in ?? () #2 0xffffffff804776c9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff80477acd in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff8072edd4 in trap_fatal (frame=0xffffff00018bc9c0, eva=18446742974225594576) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0xffffffff8072f1a5 in trap_pfault (frame=0xffffffffae6d2950, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0xffffffff8072fae8 in trap (frame=0xffffffffae6d2950) at /usr/src/sys/amd64/amd64/trap.c:410 #7 0xffffffff8071575e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0xffffffff8072436c in pmap_remove_pages (pmap=0xffffff0001ab7778) at /usr/src/sys/amd64/amd64/pmap.c:388 #9 0xffffffff80688238 in vmspace_exit (td=0xffffff00018bc9c0) at /usr/src/sys/vm/vm_map.c:404 #10 0xffffffff804577ac in exit1 (td=0xffffff00018bc9c0, rv=0) at /usr/src/sys/kern/kern_exit.c:294 #11 0xffffffff80458b5e in sys_exit (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_exit.c:98 #12 0xffffffff8072f427 in syscall (frame=0xffffffffae6d2c70) at /usr/src/sys/amd64/amd64/trap.c:852 #13 0xffffffff8071596b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:290 #14 0x00000008006a8b3c in ?? () Previous frame inner to this frame (corrupt stack?) ---- end kgdb output ---- After this, following instructions given to me, I jumped to step #8 and did a 'list' command: ---- followup output ---- (kgdb) frame 8 #8 0xffffffff8072436c in pmap_remove_pages (pmap=0xffffff0001ab7778) at /usr/src/sys/amd64/amd64/pmap.c:388 388 return (PTmap + ((va >> PAGE_SHIFT) & mask)); (kgdb) list 383 PMAP_INLINE pt_entry_t * 384 vtopte(vm_offset_t va) 385 { 386 u_int64_t mask = ((1ul << (NPTEPGSHIFT + NPDEPGSHIFT + NPDPEPGSHIFT + NPML4EPGSHIFT)) - 1); 387 388 return (PTmap + ((va >> PAGE_SHIFT) & mask)); 389 } 390 391 static __inline pd_entry_t * 392 vtopde(vm_offset_t va) ---- end followup output ---- From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 14:06:02 2008 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD1A1065675; Tue, 2 Dec 2008 14:06:02 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BC9D88FC0A; Tue, 2 Dec 2008 14:06:02 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB2E6260018446; Tue, 2 Dec 2008 14:06:02 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB2E62QK018441; Tue, 2 Dec 2008 14:06:02 GMT (envelope-from gavin) Date: Tue, 2 Dec 2008 14:06:02 GMT Message-Id: <200812021406.mB2E62QK018441@freefall.freebsd.org> To: kennethrc@gmail.com, gavin@FreeBSD.org, freebsd-amd64@FreeBSD.org, gavin@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: amd64/116457: [install] can't install freebsd on dv9420us 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: Tue, 02 Dec 2008 14:06:03 -0000 Synopsis: [install] can't install freebsd on dv9420us State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Tue Dec 2 14:04:12 UTC 2008 State-Changed-Why: Feedback timeout (6 months). I suspect this may be fixed with the BTX changes in 7.1 / 6.4. To submitter: if you do still see this problem with 7.1 let us know and we can reopen the PR. Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Tue Dec 2 14:04:12 UTC 2008 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=116457 From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 14:27:45 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF2161065670 for ; Tue, 2 Dec 2008 14:27:45 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6EDDE8FC14 for ; Tue, 2 Dec 2008 14:27:45 +0000 (UTC) (envelope-from hk@alogis.com) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.4/8.13.1) with ESMTP id mB2ED2IK002934; Tue, 2 Dec 2008 15:13:02 +0100 (CET) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.4/8.13.1/Submit) id mB2ED25C002933; Tue, 2 Dec 2008 15:13:02 +0100 (CET) (envelope-from hk) Date: Tue, 2 Dec 2008 15:13:02 +0100 From: Holger Kipp To: Jurriaan Nijkamp Message-ID: <20081202141302.GA2745@intserv.int1.b.intern> References: <200812020920.mB29K3ox098098@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812020920.mB29K3ox098098@freefall.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/129238: [panic] System randomly panics 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: Tue, 02 Dec 2008 14:27:46 -0000 On Tue, Dec 02, 2008 at 09:20:03AM +0000, Jurriaan Nijkamp wrote: > The following reply was made to PR amd64/129238; it has been noted by GNATS. > > From: "Jurriaan Nijkamp" > To: bug-followup@FreeBSD.org, > alias@jurrie.net > Cc: > Subject: Re: amd64/129238: [panic] System randomly panics > Date: Tue, 2 Dec 2008 08:13:22 +0100 (CET) > > After another crash yesterday, I got a new dump which, according to > someone who knows what he's talking about, is actually useful. He also > said the problem may lie with faulty memory, but I must say I did a > memtest86+ test last week which said my memory was working perfectly. I once had a board (high quality) with memory (high quality) with memory problems - ie a simple make -j8 buildworld would reliably panic the system, but running memtest for hours did not show any problems. It turned out to be a timing issue - we did hit exactly the combination of memory and mainboard that didn't work well together. We swapped memory with a different system and both were running fine afterwards. So please do not rely on output of memtest alone - it is not stressing the system the way real applications do. > I am pasting the output of kgdb below. Can't comment on kgdb-output. Sorry. Regards, Hoger Kipp From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 15:17:47 2008 Return-Path: Delivered-To: amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79F6A106564A; Tue, 2 Dec 2008 15:17:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 48E368FC0C; Tue, 2 Dec 2008 15:17:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB2FHji2062843; Tue, 2 Dec 2008 10:17:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id mB2FHj5K017689; Tue, 2 Dec 2008 10:17:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1627A73039; Tue, 2 Dec 2008 10:17:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20081202151745.1627A73039@freebsd-current.sentex.ca> Date: Tue, 2 Dec 2008 10:17:45 -0500 (EST) X-Virus-Scanned: ClamAV 0.94/8577/Wed Nov 5 16:05:36 2008 clamav-milter version 0.94 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2008 15:17:47 -0000 TB --- 2008-12-02 14:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2008-12-02 14:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2008-12-02 14:00:00 - cleaning the object tree TB --- 2008-12-02 14:00:24 - cvsupping the source tree TB --- 2008-12-02 14:00:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2008-12-02 14:00:32 - building world TB --- 2008-12-02 14:00:32 - MAKEOBJDIRPREFIX=/obj TB --- 2008-12-02 14:00:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2008-12-02 14:00:32 - TARGET=amd64 TB --- 2008-12-02 14:00:32 - TARGET_ARCH=amd64 TB --- 2008-12-02 14:00:32 - TZ=UTC TB --- 2008-12-02 14:00:32 - __MAKE_CONF=/dev/null TB --- 2008-12-02 14:00:32 - cd /src TB --- 2008-12-02 14:00:32 - /usr/bin/make -B buildworld >>> World build started on Tue Dec 2 14:00:35 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_files.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_kstack.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_threads.c cc -O2 -pipe -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_vm.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_vm.c: In function 'procstat_vm': /src/usr.bin/procstat/procstat_vm.c:59: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' /src/usr.bin/procstat/procstat_vm.c:60: warning: format '%*p' expects type 'void *', but argument 3 has type 'uint64_t' *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-12-02 15:17:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-12-02 15:17:45 - ERROR: failed to build world TB --- 2008-12-02 15:17:45 - 3597.14 user 359.62 system 4664.35 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 17:43:30 2008 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B022A1065676; Tue, 2 Dec 2008 17:43:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Alexander Motin Date: Tue, 2 Dec 2008 12:43:03 -0500 User-Agent: KMail/1.6.2 References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> In-Reply-To: <4932F34C.1040804@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200812021243.08513.jkim@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org, freebsd-amd64@FreeBSD.org, peter@FreeBSD.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Tue, 02 Dec 2008 17:43:30 -0000 On Sunday 30 November 2008 03:10 pm, Alexander Motin wrote: > Hi. > > Alexander Motin wrote: > > Jung-uk Kim wrote: > >> I was working on suspend/resume support for amd64 and this is > >> the result. It works with a modified QEMU (QEMU does not > >> support S3) but real boxes that I have don't seem to like it > >> (e.g., broken BIOSes). If there is someone interested in > >> finishing it off or giving it a try, the patch is here: > >> > >> http://people.freebsd.org/~jkim/amd64_suspend.diff > > > > I have tried it on my Acer TM6292. S1/S2 are unsupported. On S3 > > system successfully got down, but on wakeup button, two seconds > > after power up, even without video initialization, it shut down, > > reset and then started usual boot. I have tried both original and > > updated BIOS, without any difference. > > > > Can I give you any other help? > > I have spent a day investigating the problem. I was inserting empty > infinite loop into the different points of wakeup process trying to > find the place where system reboots. I just haven't found any other > feedback channel as video is not initialized and beeper is not > working for some reason. > > As result, I have found, that if I am inserting: > qqq: > > jmp qqq > lines before line 98 of acpi_switch.S: > movl $MSR_MTRRdefType, %ecx > > movl WAKEUP_CTX(mtrr), %eax > > wrmsr > system hangs, but if I insert it just after them - system reboots. > > With just commenting this three lines I was able to get successful > suspend/resume with UP amd64 kernel!!! Good catch! I can confirm this is a correct bandaid. We cannot restore this MSR without restoring entire MTRR map. Actually, I should have written separate functions to save/restore all global MSRs. Only per-CPU MSRs should be embedded like that. > Here is problems I still have now: > - SMP kernel resume is not working, system reboots while doing > acpi_wakeup_cpus(); My dual-core CPU seems to resume okay but quite unstable. Can you try something like the following in amd64/mp_machdep.c and tell me if it helps? ------------ @@ -57,6 +57,7 @@ #include #include +#include #include #include #include @@ -1121,6 +1121,8 @@ int cpumask = PCPU_GET(cpumask); if (savectx2(&stopxpcbs[cpu])) { + /* Flush CPU cache. */ + wbinvd(); /* Indicate that we are suspended. */ atomic_set_int(&stopped_cpus, cpumask); } else { ------------ > - text mode video does not restores on resume, while Xorg graphic > one does. hw.acpi.reset_video=1 does not help, it just hanging > resume process. It is very common problem for modern video cards. We cannot do much here without help of GPU-specific routines (e.g., ATI ATOM BIOS parser for RadeonHD) or in-kernel realmode emulation[1] (e.g., NetBSD). Thanks for the feedback! Jung-uk Kim [1] http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libx86emu/ http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/x86/x86/vga_post.c From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 19:03:51 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E637106564A; Tue, 2 Dec 2008 19:03:51 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3323A8FC0C; Tue, 2 Dec 2008 19:03:49 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 228632325; Tue, 02 Dec 2008 21:03:49 +0200 Message-ID: <49358684.7010508@FreeBSD.org> Date: Tue, 02 Dec 2008 21:03:32 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Jung-uk Kim References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <200812021243.08513.jkim@FreeBSD.org> In-Reply-To: <200812021243.08513.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-amd64@FreeBSD.org, peter@FreeBSD.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Tue, 02 Dec 2008 19:03:51 -0000 Hi. Jung-uk Kim wrote: >> Here is problems I still have now: >> - SMP kernel resume is not working, system reboots while doing >> acpi_wakeup_cpus(); > > My dual-core CPU seems to resume okay but quite unstable. Can you try > something like the following in amd64/mp_machdep.c and tell me if it > helps? > > ------------ > @@ -57,6 +57,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -1121,6 +1121,8 @@ > int cpumask = PCPU_GET(cpumask); > > if (savectx2(&stopxpcbs[cpu])) { > + /* Flush CPU cache. */ > + wbinvd(); > /* Indicate that we are suspended. */ > atomic_set_int(&stopped_cpus, cpumask); > } else { > ------------ Wow, it works! I am writing this letter just after suspending/resuming my dual-core C2D system 4 times straight. Music plays, USB, SATA, all other hardware works fine. What kind of instability do you have? The only strange effect I have noticed was incorrect CPU time some processes got: %ps ax PID TT STAT TIME COMMAND 12 ?? WL 280503:38,05 [intr] 1430 ?? Ss 280503:38,34 icewm But I think it is more timer driver related then resume itself. > Thanks for the feedback! Many thanks to you! I hope this long-waited feature will be finished! -- Alexander Motin From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 19:26:55 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE0BD106567C; Tue, 2 Dec 2008 19:26:55 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id B07498FC19; Tue, 2 Dec 2008 19:26:54 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 228634412; Tue, 02 Dec 2008 21:26:53 +0200 Message-ID: <49358BED.3030903@FreeBSD.org> Date: Tue, 02 Dec 2008 21:26:37 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Nate Lawson References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <200812021243.08513.jkim@FreeBSD.org> <49358684.7010508@FreeBSD.org> <49358A3F.7020701@root.org> In-Reply-To: <49358A3F.7020701@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: peter@FreeBSD.org, freebsd-acpi@FreeBSD.org, freebsd-amd64@FreeBSD.org, Jung-uk Kim Subject: Re: Semi-working patch for amd64 suspend/resume 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: Tue, 02 Dec 2008 19:26:56 -0000 Nate Lawson wrote: >> The only strange effect I have noticed was incorrect CPU time some >> processes got: >> %ps ax >> PID TT STAT TIME COMMAND >> 12 ?? WL 280503:38,05 [intr] >> 1430 ?? Ss 280503:38,34 icewm >> >> But I think it is more timer driver related then resume itself. > > If you are using the LAPIC timer (default), it won't be running properly > during resume. However, this wide discrepancy seems to indicate that > the timer state is not being resumed properly. What if you use the ACPI > timer (hw.timecounter.* I think are the sysctls)? As I understand, I am now using LAPIC timer for HZ generation, ACPI-fast as time source and TSC as kernel DELAY() source. %sysctl -a | grep timecounter kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) ACPI-fast(1000) HPET(900) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.nsetclock: 3 kern.timecounter.ngetmicrotime: 353840 kern.timecounter.ngetnanotime: 481 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetmicrouptime: 2014472 kern.timecounter.ngetnanouptime: 8950060 kern.timecounter.ngetbinuptime: 419099 kern.timecounter.nmicrotime: 1460084 kern.timecounter.nnanotime: 40830 kern.timecounter.nbintime: 1500942 kern.timecounter.nmicrouptime: 2210 kern.timecounter.nnanouptime: 21 kern.timecounter.nbinuptime: 1988392 kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 46767 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3274417396 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 14616414 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 3757339660 kern.timecounter.tc.TSC.frequency: 2394021468 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 There is sure some problem with LAPIC: %vmstat -i interrupt total rate ..... irq257: bge0 70774 29 cpu1: timer 17600 7 cpu1: timer 27617 11 cpu1: timer 15849 6 cpu1: timer 15413 6 cpu1: timer 877180 367 Total 2284801 957 -- Alexander Motin From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 19:31:53 2008 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A23C106564A; Tue, 2 Dec 2008 19:31:53 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi025.prodigy.net (nlpi025.sbcis.sbc.com [207.115.36.54]) by mx1.freebsd.org (Postfix) with ESMTP id 196B98FC0A; Tue, 2 Dec 2008 19:31:53 +0000 (UTC) (envelope-from nate@root.org) Received: from [10.0.5.18] (ppp-71-139-15-215.dsl.snfc21.pacbell.net [71.139.15.215]) (authenticated bits=0) by nlpi025.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id mB2JJOwW028282; Tue, 2 Dec 2008 13:19:25 -0600 Message-ID: <49358A3F.7020701@root.org> Date: Tue, 02 Dec 2008 11:19:27 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Alexander Motin References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <200812021243.08513.jkim@FreeBSD.org> <49358684.7010508@FreeBSD.org> In-Reply-To: <49358684.7010508@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Dec 2008 19:38:13 +0000 Cc: peter@FreeBSD.org, freebsd-acpi@FreeBSD.org, freebsd-amd64@FreeBSD.org, Jung-uk Kim Subject: Re: Semi-working patch for amd64 suspend/resume 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: Tue, 02 Dec 2008 19:31:53 -0000 Alexander Motin wrote: > Hi. > > Jung-uk Kim wrote: >>> Here is problems I still have now: >>> - SMP kernel resume is not working, system reboots while doing >>> acpi_wakeup_cpus(); >> >> My dual-core CPU seems to resume okay but quite unstable. Can you try >> something like the following in amd64/mp_machdep.c and tell me if it >> helps? >> >> ------------ >> @@ -57,6 +57,7 @@ >> #include >> >> #include >> +#include >> #include >> #include >> #include >> @@ -1121,6 +1121,8 @@ >> int cpumask = PCPU_GET(cpumask); >> >> if (savectx2(&stopxpcbs[cpu])) { >> + /* Flush CPU cache. */ >> + wbinvd(); >> /* Indicate that we are suspended. */ >> atomic_set_int(&stopped_cpus, cpumask); >> } else { >> ------------ > > Wow, it works! > > I am writing this letter just after suspending/resuming my dual-core C2D > system 4 times straight. Music plays, USB, SATA, all other hardware > works fine. What kind of instability do you have? Thank you both for debugging this. It's good to see progress on suspend/resume. > The only strange effect I have noticed was incorrect CPU time some > processes got: > %ps ax > PID TT STAT TIME COMMAND > 12 ?? WL 280503:38,05 [intr] > 1430 ?? Ss 280503:38,34 icewm > > But I think it is more timer driver related then resume itself. If you are using the LAPIC timer (default), it won't be running properly during resume. However, this wide discrepancy seems to indicate that the timer state is not being resumed properly. What if you use the ACPI timer (hw.timecounter.* I think are the sysctls)? -- Nate From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 21:15:13 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E646C1065825; Tue, 2 Dec 2008 21:15:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3538FC1B; Tue, 2 Dec 2008 21:15:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mB2LEsxK011443; Tue, 2 Dec 2008 16:15:07 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-amd64@freebsd.org Date: Tue, 2 Dec 2008 15:59:05 -0500 User-Agent: KMail/1.9.7 References: <1224616985.00027652.1224606603@10.7.7.3> <49358A3F.7020701@root.org> <49358BED.3030903@FreeBSD.org> In-Reply-To: <49358BED.3030903@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812021559.05492.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Tue, 02 Dec 2008 16:15:07 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8712/Tue Dec 2 12:14:43 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Alexander Motin , freebsd-acpi@freebsd.org, peter@freebsd.org, Nate Lawson Subject: Re: Semi-working patch for amd64 suspend/resume 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: Tue, 02 Dec 2008 21:15:14 -0000 On Tuesday 02 December 2008 02:26:37 pm Alexander Motin wrote: > Nate Lawson wrote: > >> The only strange effect I have noticed was incorrect CPU time some > >> processes got: > >> %ps ax > >> PID TT STAT TIME COMMAND > >> 12 ?? WL 280503:38,05 [intr] > >> 1430 ?? Ss 280503:38,34 icewm > >> > >> But I think it is more timer driver related then resume itself. > > > > If you are using the LAPIC timer (default), it won't be running properly > > during resume. However, this wide discrepancy seems to indicate that > > the timer state is not being resumed properly. What if you use the ACPI > > timer (hw.timecounter.* I think are the sysctls)? > > As I understand, I am now using LAPIC timer for HZ generation, ACPI-fast > as time source and TSC as kernel DELAY() source. > > %sysctl -a | grep timecounter > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) ACPI-fast(1000) HPET(900) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > kern.timecounter.nsetclock: 3 > kern.timecounter.ngetmicrotime: 353840 > kern.timecounter.ngetnanotime: 481 > kern.timecounter.ngetbintime: 0 > kern.timecounter.ngetmicrouptime: 2014472 > kern.timecounter.ngetnanouptime: 8950060 > kern.timecounter.ngetbinuptime: 419099 > kern.timecounter.nmicrotime: 1460084 > kern.timecounter.nnanotime: 40830 > kern.timecounter.nbintime: 1500942 > kern.timecounter.nmicrouptime: 2210 > kern.timecounter.nnanouptime: 21 > kern.timecounter.nbinuptime: 1988392 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 46767 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 3274417396 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 900 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.ACPI-fast.counter: 14616414 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.quality: 1000 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 3757339660 > kern.timecounter.tc.TSC.frequency: 2394021468 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > > There is sure some problem with LAPIC: > %vmstat -i > interrupt total rate > ..... > irq257: bge0 70774 29 > cpu1: timer 17600 7 > cpu1: timer 27617 11 > cpu1: timer 15849 6 > cpu1: timer 15413 6 > cpu1: timer 877180 367 > Total 2284801 957 Oh, it's getting a new counter on each resume. That is a bug. Ah, I think the AP's are using lapic_setup(1) when they should be using lapic_setup(0) during a resume. -- John Baldwin From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 21:37:28 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB3421065677; Tue, 2 Dec 2008 21:37:28 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4B65D8FC1B; Tue, 2 Dec 2008 21:37:27 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 228643200; Tue, 02 Dec 2008 23:37:26 +0200 Message-ID: <4935AA86.7090405@FreeBSD.org> Date: Tue, 02 Dec 2008 23:37:10 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: John Baldwin References: <1224616985.00027652.1224606603@10.7.7.3> <49358A3F.7020701@root.org> <49358BED.3030903@FreeBSD.org> <200812021559.05492.jhb@freebsd.org> In-Reply-To: <200812021559.05492.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, peter@freebsd.org, freebsd-amd64@freebsd.org, Nate Lawson Subject: Re: Semi-working patch for amd64 suspend/resume 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: Tue, 02 Dec 2008 21:37:29 -0000 John Baldwin wrote: > Oh, it's getting a new counter on each resume. That is a bug. Ah, I think > the AP's are using lapic_setup(1) when they should be using lapic_setup(0) > during a resume. Thanks. With this LAPIC works better: --- mp_machdep.c.prev2 2008-12-02 23:33:10.000000000 +0200 +++ mp_machdep.c 2008-12-02 23:26:23.000000000 +0200 @@ -1127,7 +1127,7 @@ cpususpend_handler(void) atomic_set_int(&stopped_cpus, cpumask); } else { /* Set up local APIC again. */ - lapic_setup(1); + lapic_setup(0); } while (!(started_cpus & cpumask)) But statistic problem is still here: # ps ax PID TT STAT TIME COMMAND 1429 ?? Ss 282031:03,98 icewm -- Alexander Motin From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 3 18:33:34 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E8BE106564A; Wed, 3 Dec 2008 18:33:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6828FC08; Wed, 3 Dec 2008 18:33:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mB3BEfdV023920; Wed, 3 Dec 2008 22:14:41 +1100 Received: from c220-239-225-17.carlnfd1.nsw.optusnet.com.au (c220-239-225-17.carlnfd1.nsw.optusnet.com.au [220.239.225.17]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mB3BEQtY002065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 22:14:36 +1100 Date: Wed, 3 Dec 2008 22:14:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Alexander Motin In-Reply-To: <49358BED.3030903@FreeBSD.org> Message-ID: <20081203210228.R1989@delplex.bde.org> References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <200812021243.08513.jkim@FreeBSD.org> <49358684.7010508@FreeBSD.org> <49358A3F.7020701@root.org> <49358BED.3030903@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org, peter@freebsd.org, Nate Lawson Subject: Re: Semi-working patch for amd64 suspend/resume 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: Wed, 03 Dec 2008 18:33:34 -0000 On Tue, 2 Dec 2008, Alexander Motin wrote: > Nate Lawson wrote: >>> The only strange effect I have noticed was incorrect CPU time some >>> processes got: >>> %ps ax >>> PID TT STAT TIME COMMAND >>> 12 ?? WL 280503:38,05 [intr] >>> 1430 ?? Ss 280503:38,34 icewm >>> >>> But I think it is more timer driver related then resume itself. >> >> If you are using the LAPIC timer (default), it won't be running properly >> during resume. However, this wide discrepancy seems to indicate that >> the timer state is not being resumed properly. What if you use the ACPI >> timer (hw.timecounter.* I think are the sysctls)? > > As I understand, I am now using LAPIC timer for HZ generation, ACPI-fast as > time source and TSC as kernel DELAY() source. CPU times use mainly the cpu_ticker (TSC on i386), and the cpu_ticker code has always been broken if the frequency changes a lot. The main bugs that I know about are: (1) the cpu time is (total cpu_ticks) / cputick_frequency(now) but should be the integral over previous thread history of (delta cpu_ticks) / cputick_frequency(t) dt. The former gives a wrong value if cputick_frequency(t) is not constant over previous thread history, and the wrongness is very obvious for long-running threads like intr and idle ones if the TSC frequency changes significantly (e.g., by cpufreq). cpufreq has a callback to reinitialize the frequency calibration, but this doesn't help much. I can't find any resume method for the TSC. (2) frequency _re_calibration is broken. It never decreases the frequency. Thus if the frequency is transiently high, the transiently high calibration persists until the next reinitialization of the frequency calibration (or until a tranisiently higher frequency is seen). Small variations due to temperature changes thus make the frequency persistently slightly higher that it should be, and large variations due to stopping a timer or stopping or throttling the TSC can make the freqency persistently very wrong. This wrongness is very obvious using ddb. While in ddb, interrupt timers are stopped but the TSC advances. Recalibration then gives an enormously high frequency (nearly 1/0 = infinity) that is sticky due to the bug. Dividing by this then gives all cpu times of nearly 0, modulo monotonicity enforcement by calcru() (which helps here -- old nonzero times for intr and idle remain nonzero). The sanity checking in the recalibration detects remarkably few cases of insanity for some reason, perhaps because the timers are too in sync. You seem to have the opposite problem, that times are enormously high. This would be caused by the frequency being calibrated as nearly 0, but I can't see how this could happen -- the TSC is presumably stopped while the system is suspended, so the recalibration code would tend to give a frequency far too low if the resume method is indeed missing, but bug (2) prevents this low value being used; OTOH, the resume method should recalibrate only after restarting all clocks, so it shouldn't suffer from bug (2). There are possible races getting the calibration done by the resume method before the main timer interrupt handler does it based on bogus data, but the latter doesn't happen on every timer interrupt so you would be unlucky to lose these races. If the frequency is transiently miscalibrated as nearly 0 and you look at the cpu time using calcru() during this time, then bug (1) gives enormously high times like the above (nearly 1/0) for long running processes; then calcru()'s monotonicity enforcement preserves the enormously high times almost forever (recalibration should eventually fix the frequency, so bug (1) would give normal times again since nothing much has happened to the tick counts; however monotonicity enforcement results in the transiently high times being returned almost forever -- the returned times won't even increase until the normal times reach the enormous value or another transient miscalibration messes up the calculation of the raw times again). Bruce From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 3 21:59:26 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 454A81065675 for ; Wed, 3 Dec 2008 21:59:26 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id E2B848FC17 for ; Wed, 3 Dec 2008 21:59:25 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1586321yxb.13 for ; Wed, 03 Dec 2008 13:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=xl48IeOegcjfYVgV4cSosUjW2V0JvaEOHORSEtUTNig=; b=luzGgxEsIzLo1G9nqMA89IDDIta4XaYON+YmD4rGOYQjgZDiQeeFgGcNZ6jFbtWrGy F+DVWgS4EMOVZ79ellEddNLggvWv7+JtoKog3oJ4+PxGF8fxlXVJ5CDSF3j70/5yf1sb b313q0HjxnjFVrlTJfKePxub28D3LNFBEPyww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=CHl6lQClccxOc8caJQ70yhCkrckYthnyd3bfMPieLQ0lCmTvSP/ZgFOCrEA5EmTTa7 7NbALZCuVK/uMbtXiO08Gw0RxYXWMbJHxg553Chq+uHRB4Un9mXShWdkE09R36iqBvRp i+QwtrL4Vlrit8EKLXRdQD5Yt/NBW6YNzX6Ro= Received: by 10.100.107.17 with SMTP id f17mr8083449anc.51.1228340059489; Wed, 03 Dec 2008 13:34:19 -0800 (PST) Received: by 10.101.70.6 with HTTP; Wed, 3 Dec 2008 13:34:19 -0800 (PST) Message-ID: <539c60b90812031334kfe23981s35b965b12462a5b2@mail.gmail.com> Date: Wed, 3 Dec 2008 14:34:19 -0700 From: "Steve Franks" Sender: bahamasfranks@gmail.com To: "Jung-uk Kim" In-Reply-To: <200812021243.08513.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <200812021243.08513.jkim@FreeBSD.org> X-Google-Sender-Auth: 453384557f723e9c X-Mailman-Approved-At: Wed, 03 Dec 2008 22:15:54 +0000 Cc: freebsd-acpi@freebsd.org, peter@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Wed, 03 Dec 2008 21:59:26 -0000 On Tue, Dec 2, 2008 at 10:43 AM, Jung-uk Kim wrote: > On Sunday 30 November 2008 03:10 pm, Alexander Motin wrote: >> Hi. >> >> Alexander Motin wrote: >> > Jung-uk Kim wrote: >> >> I was working on suspend/resume support for amd64 and this is >> >> the result. It works with a modified QEMU (QEMU does not >> >> support S3) but real boxes that I have don't seem to like it >> >> (e.g., broken BIOSes). If there is someone interested in >> >> finishing it off or giving it a try, the patch is here: >> >> >> >> http://people.freebsd.org/~jkim/amd64_suspend.diff >> > >> > I have tried it on my Acer TM6292. S1/S2 are unsupported. On S3 >> > system successfully got down, but on wakeup button, two seconds >> > after power up, even without video initialization, it shut down, >> > reset and then started usual boot. I have tried both original and >> > updated BIOS, without any difference. >> > >> > Can I give you any other help? >> >> I have spent a day investigating the problem. I was inserting empty >> infinite loop into the different points of wakeup process trying to >> find the place where system reboots. I just haven't found any other >> feedback channel as video is not initialized and beeper is not >> working for some reason. >> >> As result, I have found, that if I am inserting: >> qqq: >> >> jmp qqq >> lines before line 98 of acpi_switch.S: >> movl $MSR_MTRRdefType, %ecx >> >> movl WAKEUP_CTX(mtrr), %eax >> >> wrmsr >> system hangs, but if I insert it just after them - system reboots. >> >> With just commenting this three lines I was able to get successful >> suspend/resume with UP amd64 kernel!!! > > Good catch! I can confirm this is a correct bandaid. We cannot > restore this MSR without restoring entire MTRR map. Actually, I > should have written separate functions to save/restore all global > MSRs. Only per-CPU MSRs should be embedded like that. > >> Here is problems I still have now: >> - SMP kernel resume is not working, system reboots while doing >> acpi_wakeup_cpus(); > > My dual-core CPU seems to resume okay but quite unstable. Can you try > something like the following in amd64/mp_machdep.c and tell me if it > helps? > > ------------ > @@ -57,6 +57,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -1121,6 +1121,8 @@ > int cpumask = PCPU_GET(cpumask); > > if (savectx2(&stopxpcbs[cpu])) { > + /* Flush CPU cache. */ > + wbinvd(); > /* Indicate that we are suspended. */ > atomic_set_int(&stopped_cpus, cpumask); > } else { > ------------ > >> - text mode video does not restores on resume, while Xorg graphic >> one does. hw.acpi.reset_video=1 does not help, it just hanging >> resume process. > > It is very common problem for modern video cards. We cannot do much > here without help of GPU-specific routines (e.g., ATI ATOM BIOS > parser for RadeonHD) or in-kernel realmode emulation[1] (e.g., > NetBSD). > > Thanks for the feedback! > > Jung-uk Kim > > [1] http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libx86emu/ > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/x86/x86/vga_post.c > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > Do you believe these patches should work against 6.4? I should like to try it out on my trusty 'ol desktop. Best, Steve From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 3 23:14:40 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE4391065676 for ; Wed, 3 Dec 2008 23:14:40 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 6E6968FC0A for ; Wed, 3 Dec 2008 23:14:40 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1600875ywe.13 for ; Wed, 03 Dec 2008 15:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=anH9nzfzhkJ+9cr+2S0bGgX75Bixv1ocsiqGYi6EkkI=; b=ujbokqAyIquOWTEr+/Xb18K7ezotrOyW/MdsnOh3IXkMFzTPgR5mJa23KA1hFHNXge luhx3O9TENNQ2OTBTr0PZZvS1VKYAeAZO1zJmPgJf2CM5+aNz3hzZYLoC8RDd+xVXgHP OUFihHUl3pgQMHieOv27sL8G26JbHv36/WYg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=b1EYR8rmgahoyj14svRqTnlhNvfjyUVSd3YvGG7dlbN8Jc+ITbwPYZljb9hK2+WTEc yW+RQj89b6+lnn7v37leXKV15TCMpa7nanxmwCBqRzd/l6xAiRgxoe5bjNB5tex6MWt8 b8j4ZHN/R8cO1U9+4XMmIm9wtMUZs7kByEAAk= Received: by 10.100.126.19 with SMTP id y19mr8141178anc.2.1228346079657; Wed, 03 Dec 2008 15:14:39 -0800 (PST) Received: by 10.101.70.6 with HTTP; Wed, 3 Dec 2008 15:14:39 -0800 (PST) Message-ID: <539c60b90812031514x3246ca09ua2febc879f8a7fcf@mail.gmail.com> Date: Wed, 3 Dec 2008 16:14:39 -0700 From: "Steve Franks" Sender: bahamasfranks@gmail.com To: "Jung-uk Kim" In-Reply-To: <539c60b90812031334kfe23981s35b965b12462a5b2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <200812021243.08513.jkim@FreeBSD.org> <539c60b90812031334kfe23981s35b965b12462a5b2@mail.gmail.com> X-Google-Sender-Auth: 2cb7c6f041201683 X-Mailman-Approved-At: Wed, 03 Dec 2008 23:15:53 +0000 Cc: freebsd-acpi@freebsd.org, peter@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Wed, 03 Dec 2008 23:14:41 -0000 > On Tue, Dec 2, 2008 at 10:43 AM, Jung-uk Kim wrote: >> On Sunday 30 November 2008 03:10 pm, Alexander Motin wrote: >>> Hi. >>> >>> Alexander Motin wrote: >>> > Jung-uk Kim wrote: >>> >> I was working on suspend/resume support for amd64 and this is >>> >> the result. It works with a modified QEMU (QEMU does not >>> >> support S3) but real boxes that I have don't seem to like it >>> >> (e.g., broken BIOSes). If there is someone interested in >>> >> finishing it off or giving it a try, the patch is here: >>> >> >>> >> http://people.freebsd.org/~jkim/amd64_suspend.diff >>> > >>> > I have tried it on my Acer TM6292. S1/S2 are unsupported. On S3 >>> > system successfully got down, but on wakeup button, two seconds >>> > after power up, even without video initialization, it shut down, >>> > reset and then started usual boot. I have tried both original and >>> > updated BIOS, without any difference. >>> > >>> > Can I give you any other help? >>> >>> I have spent a day investigating the problem. I was inserting empty >>> infinite loop into the different points of wakeup process trying to >>> find the place where system reboots. I just haven't found any other >>> feedback channel as video is not initialized and beeper is not >>> working for some reason. >>> >>> As result, I have found, that if I am inserting: >>> qqq: >>> >>> jmp qqq >>> lines before line 98 of acpi_switch.S: >>> movl $MSR_MTRRdefType, %ecx >>> >>> movl WAKEUP_CTX(mtrr), %eax >>> >>> wrmsr >>> system hangs, but if I insert it just after them - system reboots. >>> >>> With just commenting this three lines I was able to get successful >>> suspend/resume with UP amd64 kernel!!! >> >> Good catch! I can confirm this is a correct bandaid. We cannot >> restore this MSR without restoring entire MTRR map. Actually, I >> should have written separate functions to save/restore all global >> MSRs. Only per-CPU MSRs should be embedded like that. >> >>> Here is problems I still have now: >>> - SMP kernel resume is not working, system reboots while doing >>> acpi_wakeup_cpus(); >> >> My dual-core CPU seems to resume okay but quite unstable. Can you try >> something like the following in amd64/mp_machdep.c and tell me if it >> helps? >> >> ------------ >> @@ -57,6 +57,7 @@ >> #include >> >> #include >> +#include >> #include >> #include >> #include >> @@ -1121,6 +1121,8 @@ >> int cpumask = PCPU_GET(cpumask); >> >> if (savectx2(&stopxpcbs[cpu])) { >> + /* Flush CPU cache. */ >> + wbinvd(); >> /* Indicate that we are suspended. */ >> atomic_set_int(&stopped_cpus, cpumask); >> } else { >> ------------ >> >>> - text mode video does not restores on resume, while Xorg graphic >>> one does. hw.acpi.reset_video=1 does not help, it just hanging >>> resume process. >> >> It is very common problem for modern video cards. We cannot do much >> here without help of GPU-specific routines (e.g., ATI ATOM BIOS >> parser for RadeonHD) or in-kernel realmode emulation[1] (e.g., >> NetBSD). >> >> Thanks for the feedback! >> >> Jung-uk Kim >> >> [1] http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libx86emu/ >> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/x86/x86/vga_post.c >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" >> > Do you believe these patches should work against 6.4? I should like to try it out on my trusty 'ol desktop. Best, Steve From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 4 00:07:17 2008 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F572106564A; Thu, 4 Dec 2008 00:07:17 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from mail.alkar.net (mail.alkar.net [195.248.191.95]) by mx1.freebsd.org (Postfix) with ESMTP id 742718FC0C; Thu, 4 Dec 2008 00:07:16 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (HELO mavbook.mavhome.dp.ua) by mail.alkar.net (CommuniGate Pro SMTP 5.2.10) with ESMTPS id 1743982526; Thu, 04 Dec 2008 01:37:14 +0200 Message-ID: <4937181F.5000009@FreeBSD.org> Date: Thu, 04 Dec 2008 01:37:03 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.17 (X11/20081029) MIME-Version: 1.0 To: Bruce Evans References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> <200812021243.08513.jkim@FreeBSD.org> <49358684.7010508@FreeBSD.org> <49358A3F.7020701@root.org> <49358BED.3030903@FreeBSD.org> <20081203210228.R1989@delplex.bde.org> In-Reply-To: <20081203210228.R1989@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-amd64@freebsd.org, peter@freebsd.org, Nate Lawson Subject: Re: Semi-working patch for amd64 suspend/resume 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: Thu, 04 Dec 2008 00:07:17 -0000 Bruce Evans wrote: > On Tue, 2 Dec 2008, Alexander Motin wrote: >> Nate Lawson wrote: >>>> The only strange effect I have noticed was incorrect CPU time some >>>> processes got: >>>> %ps ax >>>> PID TT STAT TIME COMMAND >>>> 12 ?? WL 280503:38,05 [intr] >>>> 1430 ?? Ss 280503:38,34 icewm >>>> >>>> But I think it is more timer driver related then resume itself. >>> >>> If you are using the LAPIC timer (default), it won't be running properly >>> during resume. However, this wide discrepancy seems to indicate that >>> the timer state is not being resumed properly. What if you use the ACPI >>> timer (hw.timecounter.* I think are the sysctls)? >> >> As I understand, I am now using LAPIC timer for HZ generation, >> ACPI-fast as time source and TSC as kernel DELAY() source. > > CPU times use mainly the cpu_ticker (TSC on i386), and the cpu_ticker code > has always been broken if the frequency changes a lot. The main bugs that > I know about are: Latest CPUs, including mine, does not change TSC frequency with EST and Cx states. So I think it is not frequency problem. I haven't checked if it specially handled, but I think, that when system suspended, timers may not be just stopped, but could also be reseted. If CPU looses all it's context, why should it keep some timer state? If timer reseted - it's value probably will go back, that may be seen as negative overflow. Here is some more related error messages I have found on resume: kernel: calcru: runtime went backwards from 5095 usec to 12 usec for pid 1544 (sh) kernel: calcru: runtime went backwards from 4704 usec to 12 usec for pid 1544 (sh) kernel: calcru: runtime went backwards from 1279 usec to 2 usec for pid 1543 (sh) kernel: calcru: runtime went backwards from 4180 usec to 9 usec for pid 1511 (moused) kernel: calcru: runtime went backwards from 11869 usec to 26 usec for pid 1435 (csh) kernel: calcru: runtime went backwards from 46399 usec to 102 usec for pid 1435 (csh) kernel: calcru: runtime went backwards from 4377 usec to 9 usec for pid 1434 (su) kernel: calcru: runtime went backwards from 10097 usec to 22 usec for pid 1432 (csh) -- Alexander Motin From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 4 00:50:05 2008 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D347106564A for ; Thu, 4 Dec 2008 00:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 546018FC16 for ; Thu, 4 Dec 2008 00:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB40o5tD014826 for ; Thu, 4 Dec 2008 00:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB40o5Fc014825; Thu, 4 Dec 2008 00:50:05 GMT (envelope-from gnats) Date: Thu, 4 Dec 2008 00:50:05 GMT Message-Id: <200812040050.mB40o5Fc014825@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Nate Eldredge Cc: Subject: Re: amd64/128259: csh(1): "`" crashes csh X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Eldredge List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2008 00:50:05 -0000 The following reply was made to PR amd64/128259; it has been noted by GNATS. From: Nate Eldredge To: bug-followup@FreeBSD.org, xxjack12xx@gmail.com Cc: Subject: Re: amd64/128259: csh(1): "`" crashes csh Date: Wed, 3 Dec 2008 16:42:09 -0800 (PST) This is incorporated into bin/129405. -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-amd64@FreeBSD.ORG Thu Dec 4 23:20:02 2008 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C73B106567B for ; Thu, 4 Dec 2008 23:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1558FC16 for ; Thu, 4 Dec 2008 23:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB4NK20M068423 for ; Thu, 4 Dec 2008 23:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB4NK16Z068416; Thu, 4 Dec 2008 23:20:01 GMT (envelope-from gnats) Resent-Date: Thu, 4 Dec 2008 23:20:01 GMT Resent-Message-Id: <200812042320.mB4NK16Z068416@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-amd64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Mark Kamichoff Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D142106564A for ; Thu, 4 Dec 2008 23:15:55 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 1D6F58FC0A for ; Thu, 4 Dec 2008 23:15:55 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mB4NFshN026395 for ; Thu, 4 Dec 2008 23:15:54 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id mB4NFsbV026394; Thu, 4 Dec 2008 23:15:54 GMT (envelope-from nobody) Message-Id: <200812042315.mB4NFsbV026394@www.freebsd.org> Date: Thu, 4 Dec 2008 23:15:54 GMT From: Mark Kamichoff To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 X-Mailman-Approved-At: Fri, 05 Dec 2008 00:11:57 +0000 Cc: Subject: amd64/129426: FreeBSD 7.0 crash after subdiskXX: detached 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: Thu, 04 Dec 2008 23:20:02 -0000 >Number: 129426 >Category: amd64 >Synopsis: FreeBSD 7.0 crash after subdiskXX: detached >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 04 23:20:01 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Mark Kamichoff >Release: FreeBSD 7.0-RELEASE-p1 >Organization: >Environment: FreeBSD dax.prolixium.com 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #0: Thu May 22 22:20:18 EDT 2008 prox@dax1.prolixium.com:/usr/obj/usr/src/sys/DAX amd64 >Description: Hi - Every 30-60 days my FreeBSD-7 server will crash with the following output: subdisk12: detached ad12: detached g_vfs_done():ad12s1d[WRITE(offset=160650805248, length=16384)]error = 6 g_vfs_done():ad12s1d[WRITE(offset=67040542720, length=16384)]error = 6 g_vfs_done():ad12s1d[WRITE(offset=80158326784, length=16384)]error = 6 g_vfs_done():ad12s1d[WRITE(offset=160691107840, length=2048)]error = 6 g_vfs_done():ad12s1d[WRITE(offset=155648786432, length=2048)]error = 6 g_vfs_done():ad12s1d[WRITE(offset=6144000, length=16384)]error = 6 g_vfs_done():ad12s1d[WRITE(offset=6160384, length=6144)]error = 6 g_vfs_done():ad12s1d[WRITE(offset=65536, length=2048)]error = 6 g_vfs_done():ad12s1d[READ(offset=160702988288, length=16384)]error = 6 g_vfs_done():ad12s1d[READ(offset=160710213632, length=16384)]error = 6 panic: vinvalbuf: dirty bufs cpuid = 0 Uptime: 30d8h8m29s Physical memory: 998 MB Dumping 316 MB: 301 285 269 253 237 221 205 ... This has been happening since the box was built about two years ago, initially running FreeBSD 6.1. I've replaced all the hardware in this box recently (including the chassis) and upgraded to FreeBSD 7.0. The crashes are all the same, varying only in the disk that becomes detached (subdisk12 or subdisk8 - either 250GB SATA disk). I haven't been able to obtain a dump of physical memory, since the machine always hard locks halfway through the dump operation. Since this is a dedicated server at a colocation facility, I don't have physical access to the server - only serial console. Please let me know what information to provide. Since I have replaced all the hardware in the machine at this point, I believe this can be eliminated as a possible culprit. Thanks! - Mark >How-To-Repeat: Unknown. Box has never attained uptime for more than 100-120 days, though. >Fix: Unknown. >Release-Note: >Audit-Trail: >Unformatted: