I'm a not quite up to speed on systemd, so I'm hoping somebody here might point me in the right direction WRT the Fedora systemd init process flow.
I'm trying to work around bug 529153: https://bugzilla.redhat.com/show_bug.cgi?id=529153
The closest to a workable solution I have come up with is:
echo -n 0000:00:1c.0:pcie04 > /sys/bus/pci_express/drivers/pciehp/unbind
So I need this to run as early as possible during the init sequence, as soon as /sys is mounted.
Before/after which services should this be done?
Gordan
On Tue, 05 Feb 2013 19:32:34 +0000 Gordan Bobic gordan@bobich.net wrote:
I'm a not quite up to speed on systemd, so I'm hoping somebody here might point me in the right direction WRT the Fedora systemd init process flow.
I'm trying to work around bug 529153: https://bugzilla.redhat.com/show_bug.cgi?id=529153
The closest to a workable solution I have come up with is:
echo -n 0000:00:1c.0:pcie04
/sys/bus/pci_express/drivers/pciehp/unbind
So I need this to run as early as possible during the init sequence, as soon as /sys is mounted.
Before/after which services should this be done?
Systemd does not execute sequentially, but in parallel, so there is no concept of before and after.
What you want is to write a custom systemd unit file which requires that local-fs.target has already completed (that makes sure that the filesystem is already mounted) and then executes your command. Then systemd will make sure that your script gets executed at the first possible opportunity after the filesystem mount.
So, you can either learn how to write a custom systemd unit file, or someone experienced in this should step in to help you. My understanding of systemd is still only descriptive at best.
HTH, :-) Marko
On 02/05/2013 10:06 PM, Marko Vojinovic wrote:
On Tue, 05 Feb 2013 19:32:34 +0000 Gordan Bobicgordan@bobich.net wrote:
I'm a not quite up to speed on systemd, so I'm hoping somebody here might point me in the right direction WRT the Fedora systemd init process flow.
I'm trying to work around bug 529153: https://bugzilla.redhat.com/show_bug.cgi?id=529153
The closest to a workable solution I have come up with is:
echo -n 0000:00:1c.0:pcie04
/sys/bus/pci_express/drivers/pciehp/unbind
So I need this to run as early as possible during the init sequence, as soon as /sys is mounted.
Before/after which services should this be done?
Systemd does not execute sequentially, but in parallel, so there is no concept of before and after.
What you want is to write a custom systemd unit file which requires that local-fs.target has already completed (that makes sure that the filesystem is already mounted) and then executes your command. Then systemd will make sure that your script gets executed at the first possible opportunity after the filesystem mount.
So, you can either learn how to write a custom systemd unit file, or someone experienced in this should step in to help you. My understanding of systemd is still only descriptive at best.
Yes, I got that part mostly figured out:
My custom service is:
====== [Unit] Description=pciehp disable DefaultDependencies=no After=local-fs.target
[Service] Type=oneshot ExecStart=echo -n 0000:00:1c.0:pcie04 > /sys/bus/pci_express/drivers/pciehp/unbind ======
Unfortunately, this isn't too useful on it's own because the machine is still stuck in the pciehp loop that makes it take hours to actually boot up, iterating over and over with:
pciehp 0000:00.1c.0:pcie04 Card present on Slot(0) pciehp 0000:00.1c.0:pcie04 Card not present on Slot(0)
I got the device ID: # lspci -n | grep 1c.0 00:1c.0 0604: 8086:3a40
And tried adding to the kernel parameters: pci_stub="8086:3a40"
but that made no difference.
If I can get the machine to boot, doing:
echo -n 0000:00:1c.0:pcie04 > /sys/bus/pci_express/drivers
fixes the problem, but the only way I've been able to make it boot is by specifying "noapic noacpi nosmp quiet" as kernel boot parameters, and that is a bit wasteful on a 12-core 24-thread machine.
Extensive googling hasn't revealed any obvious way to disable pciehp when it is built into the kernel as it is in Fedora kernels or explicitly tell it to unbind (or preferably not bind in the first place) to a specific device.
If anyone has any ideas on this, I would very much like to hear about them. As it stands every Fedora and RHEL release since F11 is completely unusable on my machine, which seems like a pretty excessively long-standing bug.
Gordan
Hi
On Tue, Feb 5, 2013 at 5:49 PM, Gordan Bobic wrote:
If anyone has any ideas on this, I would very much like to hear about them. As it stands every Fedora and RHEL release since F11 is completely unusable on my machine, which seems like a pretty excessively long-standing bug.
Might want to highlight this problem at
https://admin.fedoraproject.org/mailman/listinfo/kernel
systemd list is at
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Rahul
On 02/05/2013 11:17 PM, Rahul Sundaram wrote:
Hi
On Tue, Feb 5, 2013 at 5:49 PM, Gordan Bobic wrote:
If anyone has any ideas on this, I would very much like to hear about them. As it stands every Fedora and RHEL release since F11 is completely unusable on my machine, which seems like a pretty excessively long-standing bug.Might want to highlight this problem at
Considering the bug filed for this issue has been active and unfixed since 2009 I would very much like to think that at least somebody is aware of it: https://bugzilla.redhat.com/show_bug.cgi?id=529153
I would expect something would have been done about it in 4 years if somebody actually cared about it, though.
Gordan
Hi
On Tue, Feb 5, 2013 at 6:32 PM, Gordan Bobic wrote:
Considering the bug filed for this issue has been active and unfixed since 2009 I would very much like to think that at least somebody is aware of it: https://bugzilla.redhat.com/**show_bug.cgi?id=529153https://bugzilla.redhat.com/show_bug.cgi?id=529153
I would expect something would have been done about it in 4 years if somebody actually cared about it, though.
Sometimes bug reports fall through the cracks. It happens quite often than we expect. It helps at times to bring more attention to the issue
Rahul
Sorry, I missed this mail somehow.
On Tue, Feb 5, 2013 at 3:49 PM, Gordan Bobic gordan@bobich.net wrote:
Yes, I got that part mostly figured out:
My custom service is:
====== [Unit] Description=pciehp disable DefaultDependencies=no After=local-fs.target
[Service] Type=oneshot ExecStart=echo -n 0000:00:1c.0:pcie04 > /sys/bus/pci_express/drivers/pciehp/unbind
I don't think systemd will execute shell fragments like this. You need to wrap it in `/bin/bash -c 'command'`. Perhaps that's why it's not working.
Also, After=local-fs.target isn't strictly necessary in your case, you can be sure dracut has mounted root ro at least and that systemd has mounted /sys if your unit is being run at all. Dropping it will make sure it gets executed as early as possible.
======
Speaking of dracut, if systemd can't do this early enough, you could try doing it from the initramfs.
-T.C.
On Tue, Feb 5, 2013 at 12:32 PM, Gordan Bobic gordan@bobich.net wrote:
I'm a not quite up to speed on systemd, so I'm hoping somebody here might point me in the right direction WRT the Fedora systemd init process flow.
I'm trying to work around bug 529153: https://bugzilla.redhat.com/show_bug.cgi?id=529153
The closest to a workable solution I have come up with is:
echo -n 0000:00:1c.0:pcie04 > /sys/bus/pci_express/drivers/pciehp/unbind
So I need this to run as early as possible during the init sequence, as soon as /sys is mounted.
systemd mounts /sys very early in the boot process, before any units are started.
This should do the trick:
# cat > /etc/systemd/system/bug-529153.service [Unit] Description=Workaround Bug 529153 DefaultDependencies=no Before=sysinit.target
[Service] Type=oneshot ExecStart=/bin/bash -c'echo -n 0000:00:1c.0:pcie04 > /sys/bus/pci_express/drivers/pciehp/unbind'
[Install] WantedBy=sysinit.target ^D
# systemctl enable bug-529153.service
-T.C.
-
Gordan Bobic -
Marko Vojinovic -
Rahul Sundaram -
T.C. Hollingsworth