You are not logged in.
Now I can see very strange behavior: kernel 3.2.12 boots fine without any additional kernel parameters like pcie_aspm=force.
And now I have no any idea how to reproduce this bug.
It's very strange...
Offline
Does disabling aspm (pcie_aspm=off) help as well?
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline
Does disabling aspm (pcie_aspm=off) help as well?
It did the trick for me.
Last edited by gr2mx (2012-03-24 11:32:45)
Offline
Having the same problem. My system freezes at loading ramdisk. Running on a Z68X-UD3H-B3 motherboard. I'll try these parameters mentioned previously and post back with my results.
Offline
pcie_aspm=off
dont works for me, boot hanged
pcie_aspm=force
Boot Ok
Offline
pcie_aspm=off
dont works for me, boot hanged
pcie_aspm=force
Boot Ok
I can say the same. The same is true on the recent LTS kernel update as well. I wish I had searched for this thread prior to doing a reinstall
Offline
same problem with ASUS's P8H67 / i5-2300 / dataland 6870.
I have downgraded the linux to 3.2.6.
Offline
Same problem was on my machine, and one member pointed me to this thread. This is bad to say but i am glad to see that i am not alone in this. Thanks for workaround.
"The flesh knows it suffers even when the mind has forgotten."
Offline
I've tried the workaround pcie_aspm=force and I still can't boot if I use any kernel above 3.2.1-1 on ARCH or indeed 3.2.0-17 on my Ubuntu partition. Suppose I could try pcie_aspm=off?
I'm using a Dell Studio XPS 13 laptop. Strange, had high hopes for the workaround which seems to work for everyone else who's reported..
Offline
Hello,
I have this issue, too. I've noticed by upgrading to linux 3.2.12.
No problem, I thought, and booted linux-lts 3.0.24.
But then after the update I made stupidly to linux-lts 3.0.25 the problem appears with the lts kernel, too.
I downgraded to linux 3.2.11 for now.
Your Finest Bug
Offline
FYI this manifested a bit differently for me. I didn't get a visible kernel panic/backtrace (probably because of my GRUB2 VGA settings) and I had assumed the problem was related to the recent GRUB2 updates I saw happen. The boot process would proceed past the menu and then I would just sit on a completely blank black screen. No input from the keyboard was accepted (though I didn't try sysrq). So I spent some time trying to rebuild my GRUB2 conf and reinstall it to no avail.
Then I found this thread and tried pcie_aspm=force which allowed me to boot successfully. At first I thought it wasn't applicable since someone said the problem didn't affect newer boards -- I have a P67A-UD7-B3.
Offline
I have a GA-Z68AP-D3 and tried to boot with both BIOS version F6 and F7 neither worked. pcie_aspm=force worked in both cases and I downgraded to 3.2.11 for now.
Offline
anybody upgraded to 3.2.13? does it solve the problem?
Offline
anybody upgraded to 3.2.13? does it solve the problem?
I ran into the same problem with 3.3 as well, so I doubt it works in 3.2.13.. Could not find anything about this in the changelog either
Last edited by krigun (2012-03-26 10:50:16)
Offline
Again, HERE is the official kernel bug report. Supposedly the supplied patch fixes this issue. Unverified by me, but you could attempt to recompile the arch kernel with the supplied patch.
EDIT: Noticed that the bug report does not contain any patch, but describes the commit that caused the problem. Basically you need to revert this:
f043ddb60c84ea64a23b755004572afe922e653c PCI: ignore pre-1.1 ASPM
quirking when ASPM is disabled
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 1cfbf22..24f049e 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -500,6 +500,9 @@ static int pcie_aspm_sanity_check(struct pci_dev *pdev)
int pos;
u32 reg32;
+ if (aspm_disabled)
+ return 0;
+
Last edited by krigun (2012-03-26 11:16:03)
Offline
FYI this manifested a bit differently for me. I didn't get a visible kernel panic/backtrace (probably because of my GRUB2 VGA settings) and I had assumed the problem was related to the recent GRUB2 updates I saw happen. The boot process would proceed past the menu and then I would just sit on a completely blank black screen. No input from the keyboard was accepted (though I didn't try sysrq). So I spent some time trying to rebuild my GRUB2 conf and reinstall it to no avail.
Then I found this thread and tried pcie_aspm=force which allowed me to boot successfully. At first I thought it wasn't applicable since someone said the problem didn't affect newer boards -- I have a P67A-UD7-B3.
Exactly the same behaviour here, with an Asus P8P67 Board. pcie_aspm=force allowed me to boot again.
Offline
FYI this manifested a bit differently for me. I didn't get a visible kernel panic/backtrace (probably because of my GRUB2 VGA settings) and I had assumed the problem was related to the recent GRUB2 updates I saw happen. The boot process would proceed past the menu and then I would just sit on a completely blank black screen.
Perhaps you are using loglevel=0 kernel parameter? I bet you see the kernel panic if you use loglevel=7
I know this because I tried loglevel=0, and the screen was just blank
Last edited by krigun (2012-03-26 17:54:14)
Offline
I've tried the workaround pcie_aspm=force and I still can't boot if I use any kernel above 3.2.1-1 on ARCH or indeed 3.2.0-17 on my Ubuntu partition. Suppose I could try pcie_aspm=off?
I'm using a Dell Studio XPS 13 laptop. Strange, had high hopes for the workaround which seems to work for everyone else who's reported..
If anybody should wonder what the pcie_aspm parameter controls, read this article.
As i read it, enabling or disabling pcie_aspm(whatever's rigth for your machine), shuold in worst case result in a higher power comsumption.
I wouldn't upgrade a production-server, though...
Last edited by fire_dragon (2012-03-27 11:05:18)
Offline
...
I wouldn't upgrade a production-server, though...
I did... -_-
Fortunately it's only being restarted once in a week (turned off for the weekend), and during the last week I upgraded my home PC, and find this bug. From that time I don't dare to restart the server at the office, as it is a Sandy Bridge based machine, and forbade everybody else to do such thing...
Offline
fire_dragon wrote:...
I wouldn't upgrade a production-server, though...I did... -_-
Fortunately it's only being restarted once in a week (turned off for the weekend), and during the last week I upgraded my home PC, and find this bug. From that time I don't dare to restart the server at the office, as it is a Sandy Bridge based machine, and forbade everybody else to do such thing...
Hmmm...
I would set pcie_aspm=force in the bootloader.
There's a fair chance your server will get back online, just in case someone or something boots your server.
Offline
Lenry wrote:fire_dragon wrote:...
I wouldn't upgrade a production-server, though...I did... -_-
Fortunately it's only being restarted once in a week (turned off for the weekend), and during the last week I upgraded my home PC, and find this bug. From that time I don't dare to restart the server at the office, as it is a Sandy Bridge based machine, and forbade everybody else to do such thing...Hmmm...
I would set pcie_aspm=force in the bootloader.
There's a fair chance your server will get back online, just in case someone or something boots your server.
I know, and if something happens, that will be the first thing to try, as it worked at home, but that doesn't work in every occasion, as we can see the example of pepedopolous.
Offline
According to the previus link, If you use pcie_aspm=force on a system that don't support it, the system will stop responding.
That could explain the different behavior.
But your are right... I wouldn't trust it blindly either.
Offline
I'm assuming that linux 3.2.13 isn't going to work either considering 3.3 didn't work.
Offline
I'm assuming that linux 3.2.13 isn't going to work either considering 3.3 didn't work.
Tried it, did not work..
Offline
Just reporting in that I, too, have the same issue. The force option is a workaround here. I'm on a Gigabyte P67A-UD7-B3. Looking through this thread, two things have been linked with patches:
a patch to pcie_clear_aspm in drivers/pci/pcie/aspm.c
and a patch to pcie_aspm_sanity_check in the same file
Have either of these been tested/proven to work for anyone?
Offline