System frezes at PM startup

[rbri]

After switching from 3.19.14 to 3.19.15 the trap from #524 is gone. Thanks for fixing. But now the system stops at PM startup. I can see the desktop background (but not the desktop background image) and the mouse wait cursor. Nothing more happens, no chance to move the mouse.

When setting back the /MAXCPU=1 the system starts without problems. I did the warpin install, so i think i have all updated dll's in place.

Thanks for the support

[David Azarewicz]

Please use ALT-F2 or ALT-F4 at the white blob and let me know the last config.sys statement to execute before the hang.

[rbri]

pic of the last visible screen before pm starts (and hangs)

[BlondeGuy]

I have an Intel G41-based machine that stops processing Config.sys in the same place on 3.19.15. It worked fine with 3.19.14. I'm curious to see what the resolution of this issue will be. If I get time to take a proper testlog, I'll open my own bug.

[BlondeGuy]

I thought more about what is written in the Wiki, and I commented out the run=AcpiDaemon.Exe line in config.sys. Now my Intel G41-based machine boots just fine with no parameters in the ACPI.PSD line.

[David Azarewicz]

@BlondeGuy - Your problem is not likely related to this ticket, but instead appears to be the same problem as ticket 530.

[David Azarewicz]

I don't know if any of the recent fixes have addressed your problem but it would be good to know if the latest 3.20.01 version fixes anything for you.

[rbri]

Sorry, but version 3.20.1 did not fix the problem. When i use /MAXCPU=2 (or suppress this switch) the driver loads fine but the system still freezes at PM startup. So no change with the new version.

BTW: I have one good news; i tested your new multimac and my system works well with this network driver (RTL8111). So i was able to remove my old 3C905 card and use the network support of the motherboard. Thanks a lot....

[David Azarewicz]

Replying to rbri:

Sorry, but version 3.20.1 did not fix the problem. When i use /MAXCPU=2 (or suppress this switch) the driver loads fine but the system still freezes at PM startup. So no change with the new version.

Are you using the /VW switch, by any chance? You should not be unless you specifically need it for some reason (like SCSI drivers). Your particular motherboard may not work with the /VW switch. See http://svn.netlabs.org/acpi/wiki/KnownProblems

BTW: I have one good news; i tested your new multimac and my system works well with this network driver (RTL8111). So i was able to remove my old 3C905 card and use the network support of the motherboard. Thanks a lot....

I just released R8169 version 0.0.4 this morning. It still has some minor issues, but contains a few significant fixes. It should make it into the betazone later today or tomorrow.

[rbri]

Replying to dazarewicz:

Are you using the /VW switch, by any chance? You should not be unless you specifically need it for some reason (like SCSI drivers). Your particular motherboard may not work with the /VW switch. See http://svn.netlabs.org/acpi/wiki/KnownProblems

As far as i understand your comments in #524 i have to use it.

[David Azarewicz]

Replying to rbri:

Replying to dazarewicz:

Are you using the /VW switch, by any chance? You should not be unless you specifically need it for some reason (like SCSI drivers). Your particular motherboard may not work with the /VW switch. See http://svn.netlabs.org/acpi/wiki/KnownProblems

As far as i understand your comments in #524 i have to use it.

Oops, sorry, you are correct. It seems that your hardware has two issues. 1) in Mode 2, there are more interrupts used than the kernel can handle, and 2) your motherboard has the spurious interrupt problem in mode 1. That really sucks.

What kind of system do you have?

What is the model number of the motherboard?

The reason you cannot boot in mode 2 (no switches) is that you have a device that uses an interrupt number higher than 31. It is OK to have more than 32 interrupts numbers, but if any are actually used that are higher than 31, you will get the IPE trap. If you can get your system to not use any interrupts higher than 31, you will be able to boot without the /VW switch.

Do you have any PCI cards plugged in?

If you have PCI cards, moving them to different slots will change what interrupt they use.

Does your BIOS have the ability to reassign or reserve interrupts?

If you can program the BIOS to not use any interrupts higher than 31, you will be able to boot in mode 2 and probably run fine.

[rbri]

My board is a ALliveDual-eSATA2. At the moment i us a soundblaster soundcard and a tv card. Will try tomorrow without this cards. Maybe that helps. As far as i know there are no special setting in the bios to affect the interrupts. But i will check that also.

The board or chipset seems to have some nice features. I already had a log story for the usb support (see: ​http://svn.netlabs.org/usb/ticket/2#comment:76).

[David Azarewicz]

Would you be willing to try a test PSD and run some tests for me?

Does your system have a serial port and if so, can you capture the output from it on another PC? If not, that's ok, I can come up with other options.

[rbri]

Replying to dazarewicz:

Would you be willing to try a test PSD and run some tests for me?

Yes.

Does your system have a serial port and if so, can you capture the output from it on another PC? If not, that's ok, I can come up with other options.

I think yes, but it will need some time to setup this. No idea if my old laptop is still working (the only machine with a serial connector for reading the output).

[David Azarewicz]

Replying to rbri:

Replying to dazarewicz:

Would you be willing to try a test PSD and run some tests for me?

Yes.

Does your system have a serial port and if so, can you capture the output from it on another PC? If not, that's ok, I can come up with other options.

I think yes, but it will need some time to setup this. No idea if my old laptop is still working (the only machine with a serial connector for reading the output).

I spent some time reading your ACPI tables, but it is far too complex for me to be able to figure out which device is causing the problem and if there are any options. I really need to know how the PSD is trying to configure the system in mode 2. If you manage to get a setup where you can capture the serial port output that will tell me what I need to know.

You do not need any serial port drivers installed on the system under test. It is ok if you do, but they are not used by the PSD. In debug output mode, the PSD talks directly to the hardware.

The instructions under "Collecting a Serial Port Log" at http://svn.netlabs.org/acpi/wiki/TestingGuide are exactly what I need. There is only a slight chance that there will be any options for a configuration that might work.

[rbri]

Ok, will try to setup during the next days...

[rbri]

Ok, my setup now works. Have an old dos laptop with qmodem now running and did some test already. Will attach the current output of the boot process.

[David Azarewicz]

Thanks for the log. Unfortunately you did it with the switches: /VW /MAXCPU=1 /DBGLVL=3 /O1

This only produces output for the /VW configuration with only 1 cpu. That is not what I need. Please capture another log using the /DBGLVL=3 /O1 switches only. Do not use the /VW or the /MAXCPU switches.

Also, your laptop seems to be having quite a bit of trouble keeping up with the output. Is there a way you can turn hardware handshaking (RTS/CTS) on? If not, I'll do the best I can with what I get.

[rbri]

debug output of the boot process with 3.20.01

[rbri]

debug output of the boot process with 3.20.01 without parameters

[rbri]

debug output of the boot process with 3.20.01 with /VW

[rbri]

RTS/CTS was on for the new/refreshed traces.

[David Azarewicz]

Please send me an e-mail (david at 88watts dot net) so I can send you a test PSD privately.

[rbri]

Done.

[rbri]

I think we can close this issue. The driver works stable here, all remaining issues are described as open issues or known problems.

[David Azarewicz]

For the record, please tell me how you are running the system (which switches you are using for the PSD) and what the remaining problems are. Thanks

[rbri]

Replying to dazarewicz:

For the record, please tell me how you are running the system (which switches you are using for the PSD) and what the remaining problems are. Thanks

The systems runs stable with this:

PSD=ACPI.PSD /NOHLT

Remaining issues:

• /VW switch does not work
• not all devices are accessable (high interrupts)
• EmperoarTV hangs directly when the video output starts

[David Azarewicz]

Replying to rbri:

I think we can close this issue. The driver works stable here, all remaining issues are described as open issues or known problems.

Ok, I am closing this ticket.

[rbri]

Just for the record: I bought a new board (ASUS M5A78L) last week. ACPI and SNAP works without problems so far.