Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Problems in power management at boot #8

Closed
Samsagax opened this Issue Dec 22, 2011 · 12 comments

Comments

Projects
None yet
3 participants
Owner

Samsagax commented Dec 22, 2011

I've noticed if the primary X server is probing devices and the card is switched after the X server started but before it completed all detections. This is before it gets you to the login screen. It will freeze with a "service unavailable".

I wonder if we could get our hands/test the Dave Arlie's changes on X server to support hot-pluging.

I see two workarounds to this issue: Wait a certain time after the daemon starts to switch the card. Or wait until the display manager kicks in or the X server stops probing all devices.

Owner

Lekensteyn commented Dec 22, 2011

Could you post any logs? Does this only happen if a driver is loaded (vga_switcheroo+nouveau) or without (bbswitch or acpi_call?).
In the former case, perhaps the probe function can be patched to avoid scanning if the card is off.

Member

Thulinma commented Dec 22, 2011

Meanwhile, I can add an option to wait for a certain X display to become available before activating the daemon code. That would be a good workaround, right?

Something along the lines of this in the config file:

WAITFOR=:0

And then it will wait until display :0 is available before doing anything at all. Heck, we could have this on by default. I'd say 99.9% of people will have their main display as :0, right? And the ones that do not, will know that they need to change the setting :P

Owner

Lekensteyn commented Dec 22, 2011

That's an ugly hack. It's a dependency problem which needs to be managed by the startup thingeys (Upstart, systemd, etc.). What would happen if the X server is restarted (for example, if you re-login)? The problem likely persists.

Member

Thulinma commented Dec 22, 2011

Hmm.... True. It's a workaround for most cases, though. As this is not really a problem we should be fixing in bumblebeed, I think it's a nice method until the root cause is fixed elsewhere.

Also, keep in mind that this is an issue when X is started and the card is switched before detections are complete. After the first boot, the likeliness of this happening is pretty damn slim.

Owner

Lekensteyn commented Dec 22, 2011

Let's wait for sam to provide more information. Perhaps a modification in the xorg configuration "fixes" it, but the underlying problem is likely more complicated. I guess X or the kernel modules needs to be patched.

Member

Thulinma commented Dec 22, 2011

Sure. Maybe it's an isolated case or something like that. We'll wait and see :-)

Owner

Samsagax commented Dec 22, 2011

Sorry I just dropped the bomb and left. Was just passing the bill so you would notice the latest change I did. Currently I'm trying to test arlied linux/drm/xserver/xf86-video code (saw a lot of nice changes out there). Will report back with the issue in a couple minutes.

Owner

Samsagax commented Dec 23, 2011

Nothing I can see in those, I'm affraid. But maybe adding a check for the first server started successfully before turning the card off should be a good thing

Owner

Lekensteyn commented Jan 4, 2012

I believe that this is more an issue with vgaswitcheroo than bbd. Can it be closed?

Member

Thulinma commented Jan 4, 2012

I don't know... can anyone besides @Samsagax reproduce this problem? If not, I'd say close it.

Owner

Samsagax commented Jan 4, 2012

Specifically is about GDM and vga-switcheroo. I don't know if anyone can reproduce this on any other combination.

@Samsagax Samsagax closed this Jan 10, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment