Guest mc_kool Posted November 30, 2004 Report Share Posted November 30, 2004 Hi, I installed MDK 10.0 on my nforce2 computer - ASUS A7N8X-X. Using Nvidia 1.0_6629 drivers. When I try to shutdown it down it performs a logout instead. I log back in a do another shutdown, this time it works but when I reboot it detects the 'the computer was not correctly shutdown' and performs disk checking etc, meaning something had crashed on the 1st shutdown. Setting 'no apic' and 'no local apic' from the MCC reduced the frequency of the problem however it still occurs from time to time. Does anyone no if this problem can be attributed to the nforce2 APIC problem? Also I experienced a couple of freezes when installing MDK 10.0, it worked on the 3rd attempt. As I have no problems when using Windows this problem must be s/w, either in the linux kernel or the linux force2 drivers. Is there a fix for the APIC problem? Also is this APIC problem related to advance power management as when running linux my computer does not enter suspend mode when left idle, in Windows this works fine. Thanks. Quote Link to comment Share on other sites More sharing options...
Sarissi Posted November 30, 2004 Report Share Posted November 30, 2004 (edited) I suspect it may be Mandrake's APIC problem. SuSE 9.2 Pro has no problems shutting down my Gigabyte GA-7N400-L nForce2 mobo. Mandrake 10.0 CE Powerpack gets to the shutdown at end of init 6 (I think) and I have to turn the computer off manually. SuSE 9.2 Pro turns the computer off. Go figure. (shrug) Found the solution in another thread: Add acpi=on to the append line in the bootloader, reboot, and it works fine. (also check enable acpi) Edited November 30, 2004 by Sarissi Quote Link to comment Share on other sites More sharing options...
Guest mc_kool Posted December 2, 2004 Report Share Posted December 2, 2004 Sarissi, thanks for your comments, they pointed me in the right direction. Here's where I'm at right now. linux abnormal shutdown ####################### As stated before when I use Actions->reboot from GNOME, linux doesn't shutdown properly and instead of shutting the computer down I get logged out instead. When I reboot linux performs a forced fsck and then reboots. Very annoying. I discovered the /var/log/daemon/errors log file full of the following error messages: Dec 2 18:53:38 localhost mdkkdm[2370]: Fatal X server IO error: Broken pipe Dec 2 18:53:39 localhost rpc.statd[1128]: Caught signal 15, un-registering and exiting. Note that the 'FATAL X server IO" error is always logged when starting linux. The shutdown problem only occurs when the 'Caught signal 15' error is logged following the 'Fatal X server IO' error. Does anyone know what this means? I googled 'FATAL X server IO' and found the following info. ================================================================================ ===== Subject: 188) How do I catch the "close window" event to avoid "fatal IO error"? Several windows managers offer a function such as f.kill or f.delete which sends a message to the application that it should delete its window; this is usually interpreted as a shutdown message. The application needs to catch the WM_DELETE_WINDOW client message. There is a good example in the xcalc sources in X11R5. Motif-based applications should in addition set the resource XmNdeleteResponse on the top-level shell to XmDO_NOTHING, whether they are using the Motif window manager or not. If the application doesn't handle this message the window manager may wind up calling XKillClient, which disconnects the client from the display and typically gives an Xlib error along the lines of "fatal IO error 32 (Broken pipe)". ================================================================================ ===== Also I'm using the GNOME desktop on MDK 10.0, however I noticed from the process list that the KDE manager 'kdm' is running instead of the GNOME manager 'gdm', is this normal? Getting ACPI running on MDK 10.0 ################################ Ok, I made a little progress here. 1. I setup acpi=force in lilo 2. I installed apci & apcid from mcc installer (located on DISK1) So now the acpi daemon starts and can be verified from process display and mcc - services. However when i run $acpi it doesn't display any info and when I look at the files under /proc/acpi they're all empty. dmesg output logs ... ACPI - config ACPI: Subsystem revision 20040211 Looking for DSDT in initrd ... not found! From my investigations the acpi DSDT is a very important table of data which is passed up from the BIOS. I've verified my BIOS settings, acpi is on and besides ACPI Windows works fine. Does anyone have any experience with setting up acpi on MDK 10.0? need help badly, 3 weeks since I installed MDK 10.0 and still trying to get this working. thanx. Quote Link to comment Share on other sites More sharing options...
Guest mc_kool Posted December 2, 2004 Report Share Posted December 2, 2004 On the ACPI DSDT problem, I found some doco on how to update the DSDT table ... http://forums.gentoo.org/viewtopic.php?t=122145 Also gonna try to use a recompiled DSDT file sourced from a DSDT repository ... http://acpi.sourceforge.net/dsdt/view.php?manufacturer=ASUS Quote Link to comment Share on other sites More sharing options...
Sarissi Posted December 2, 2004 Report Share Posted December 2, 2004 I didn't install anything. I merely did the thing in the bootloader dialog in MCC. Then I add acpi=on to the append line by editing the default kernel (in my case = enterprise for 1.5 GB ram). Enabling acpi in bootloader mcc dialog only removes acpi references in the append line. Question regarding your login: do you use the auto login? I found endless problems with this method in mandrake. So I use normal login and have no problems when rebooting. Now I have no problems when I do a shutdown. Make sure acpi is enabled in your bios. Remember that I am using Mandrake Linux 10.0 Community Edition Powerpack with no updates. I use auto login in SuSE 9.2 Pro and have no problems at all. Go figure. LOL Quote Link to comment Share on other sites More sharing options...
Guest mc_kool Posted December 15, 2004 Report Share Posted December 15, 2004 Just as a follow up I was unable to fix the system shutdown problem. I've since installed the recently released Fedora Core 3 and have no problems performing a system reboot from the GNOME actions menu. I think the problem was Mandrake/GNOME related as there was never any probs with "$shutdown -r" now from the console. As I moved to fedora, I didn't pursue fixing up ACPI/DSDT on mandrake. However on Fedora I still had to fix the errors/warnings in the DSDT code supplied to the kernel by the BIOS and install it into the kernel by rebuilding/recompiling the kernel. Even with the fixed DSDT, ACPI support under linux 2.6.9 has very little of the ACPI functionality implemented while with Windows you get the worx, system suspend, monitor/video suspend, disk shutdown on idle, etc. All this has been around since windows 98. With time ACPI support within linux will get better. Quote Link to comment Share on other sites More sharing options...
adamw Posted December 16, 2004 Report Share Posted December 16, 2004 disk shutdown on idle is nothing to do with ACPI, really, and is implemented by hdparm in Linux. Read the hdparm manpage for details on how to change the setting (you can make disks spin down after an arbitrary delay - on my laptop I have it set to 15 minutes when plugged into AC power, and 30 seconds when on battery power, thanks to some /etc/acpi magic). System suspend *is* implemented in Linux and works fine on some setups (my four year old laptop suspends to RAM and resumes perfectly, though it won't properly sleep to disk). The problem is that every manufacturer has a slightly different interpretation of ACPI and many of them are just, frankly, broken - throw in the myriad different pieces of hardware that can be plugged into a PC and you have...trouble :). Manufacturers design and test their systems on Windows, so they make sure it works on Windows, even if they aren't following ACPI specs. They don't do any testing on Linux, and they don't care if it doesn't work. So the acpi4linux guys are stuck with the fairly thankless task of attempting to work around thousands of non-standard ACPI implementations. This is why things aren't perfect yet :). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.