[opensuse-kernel] s2r fails for kotd on openSUSE 11.3
I gave the kernel of the day (2.6.37-rc2-1.99.2.facd623-default) a spin on an up-to-date openSUSE 11.3 system and everything works like a charm, except for one thing -- suspend to RAM (or disk for that matter). Digging into this a bit, I found that it seems to be tpm modules that cause this, and after unloading them suspend works again: # lsmod | grep tpm tpm_tis 12002 0 tpm 17401 1 tpm_tis tpm_bios 6748 1 tpm # rmmod tpm_tis # rmmod tpm # rmmod tpm_bios # lsmod | grep tpm # Does it make sense to file a Bugzilla for such a case, or will that be an immediate INVALID or WONTFIX? What kind of information in addition to the above and the relevant snippet of dmesg below would be helpful in case? Gerald [52145.975726] PM: Syncing filesystems ... done. [52146.328603] PM: Preparing system for mem sleep [52146.328757] Freezing user space processes ... (elapsed 0.01 seconds) done. [52146.344111] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [52146.360116] PM: Entering mem sleep [52146.360209] Suspending console(s) (use no_console_suspend to debug) [52146.516254] sd 0:0:0:0: [sda] Synchronizing SCSI cache [52146.516635] sd 0:0:0:0: [sda] Stopping disk [52146.580137] tpm_tis 00:0a: tpm_transmit: tpm_send: error -5 [52146.580145] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5 [52146.580148] PM: Device 00:0a failed to suspend: error -5 [52146.887770] PM: Some devices failed to suspend [52146.887811] sd 0:0:0:0: [sda] Starting disk [52147.376142] PM: resume of devices complete after 488.367 msecs [52147.376336] PM: Finishing wakeup. [52147.376338] Restarting tasks ... done. [52147.378718] video LNXVIDEO:00: Restoring backlight state [52148.368235] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X [52148.424106] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X [52148.424409] ADDRCONF(NETDEV_UP): eth0: link is not ready [52148.454024] ADDRCONF(NETDEV_UP): wlan0: link is not ready [52151.999068] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0 [52153.309755] PM: Syncing filesystems ... done. [52153.861875] PM: Preparing system for mem sleep [52153.862037] Freezing user space processes ... (elapsed 0.03 seconds) done. [52153.892124] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [52153.908123] PM: Entering mem sleep [52153.908216] Suspending console(s) (use no_console_suspend to debug) [52154.062757] sd 0:0:0:0: [sda] Synchronizing SCSI cache [52154.063092] sd 0:0:0:0: [sda] Stopping disk [52154.120139] tpm_tis 00:0a: tpm_transmit: tpm_send: error -5 [52154.120146] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5 [52154.120149] PM: Device 00:0a failed to suspend: error -5 [52154.439124] PM: Some devices failed to suspend [52154.439157] sd 0:0:0:0: [sda] Starting disk [52154.912092] PM: resume of devices complete after 472.963 msecs [52154.912286] PM: Finishing wakeup. [52154.912287] Restarting tasks ... done. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
I don't have tpm module, and without them the 2.6.37-rc2 (under factory/11.4 in my case) suspend to ram and disk is ok ( there are number 4 & 5 on my test list :-) ) But actually I know that a new release will be published very soon (-rc3) and perharps for the M4 step. So at your place I would wait until this one and retry with it. On 11/24/2010 08:21 PM, Gerald Pfeifer wrote:
I gave the kernel of the day (2.6.37-rc2-1.99.2.facd623-default) a spin on an up-to-date openSUSE 11.3 system and everything works like a charm, except for one thing -- suspend to RAM (or disk for that matter).
Digging into this a bit, I found that it seems to be tpm modules that cause this, and after unloading them suspend works again:
# lsmod | grep tpm tpm_tis 12002 0 tpm 17401 1 tpm_tis tpm_bios 6748 1 tpm # rmmod tpm_tis # rmmod tpm # rmmod tpm_bios # lsmod | grep tpm #
Does it make sense to file a Bugzilla for such a case, or will that be an immediate INVALID or WONTFIX?
What kind of information in addition to the above and the relevant snippet of dmesg below would be helpful in case?
Gerald
[52145.975726] PM: Syncing filesystems ... done. [52146.328603] PM: Preparing system for mem sleep [52146.328757] Freezing user space processes ... (elapsed 0.01 seconds) done. [52146.344111] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [52146.360116] PM: Entering mem sleep [52146.360209] Suspending console(s) (use no_console_suspend to debug) [52146.516254] sd 0:0:0:0: [sda] Synchronizing SCSI cache [52146.516635] sd 0:0:0:0: [sda] Stopping disk [52146.580137] tpm_tis 00:0a: tpm_transmit: tpm_send: error -5 [52146.580145] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5 [52146.580148] PM: Device 00:0a failed to suspend: error -5 [52146.887770] PM: Some devices failed to suspend [52146.887811] sd 0:0:0:0: [sda] Starting disk [52147.376142] PM: resume of devices complete after 488.367 msecs [52147.376336] PM: Finishing wakeup. [52147.376338] Restarting tasks ... done. [52147.378718] video LNXVIDEO:00: Restoring backlight state [52148.368235] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X [52148.424106] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X [52148.424409] ADDRCONF(NETDEV_UP): eth0: link is not ready [52148.454024] ADDRCONF(NETDEV_UP): wlan0: link is not ready [52151.999068] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0 [52153.309755] PM: Syncing filesystems ... done. [52153.861875] PM: Preparing system for mem sleep [52153.862037] Freezing user space processes ... (elapsed 0.03 seconds) done. [52153.892124] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [52153.908123] PM: Entering mem sleep [52153.908216] Suspending console(s) (use no_console_suspend to debug) [52154.062757] sd 0:0:0:0: [sda] Synchronizing SCSI cache [52154.063092] sd 0:0:0:0: [sda] Stopping disk [52154.120139] tpm_tis 00:0a: tpm_transmit: tpm_send: error -5 [52154.120146] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5 [52154.120149] PM: Device 00:0a failed to suspend: error -5 [52154.439124] PM: Some devices failed to suspend [52154.439157] sd 0:0:0:0: [sda] Starting disk [52154.912092] PM: resume of devices complete after 472.963 msecs [52154.912286] PM: Finishing wakeup. [52154.912287] Restarting tasks ... done.
-- Bruno Friedmann (irc:tigerfoot) Ioda-Net Sàrl www.ioda-net.ch openSUSE Member User www.ioda.net/r/osu Blog www.ioda.net/r/blog fsfe fellowship www.fsfe.org GPG KEY : D5C9B751C4653227 vcard : http://it.ioda-net.ch/ioda-net.vcf -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, 24 Nov 2010, Gerald Pfeifer wrote:
I gave the kernel of the day (2.6.37-rc2-1.99.2.facd623-default) a spin on an up-to-date openSUSE 11.3 system and everything works like a charm, except for one thing -- suspend to RAM (or disk for that matter).
Digging into this a bit, I found that it seems to be tpm modules that cause this, and after unloading them suspend works again:
# lsmod | grep tpm tpm_tis 12002 0 tpm 17401 1 tpm_tis tpm_bios 6748 1 tpm # rmmod tpm_tis # rmmod tpm # rmmod tpm_bios # lsmod | grep tpm #
Does it make sense to file a Bugzilla for such a case, or will that be an immediate INVALID or WONTFIX?
Actually, I am seeing exactly that as well on my x200s after putting 2.6.37-rc2 there. I am adding Rafael to CC in case it rings any bell immediately. If not, it's definitely worth upstream bugreport. Thanks.
What kind of information in addition to the above and the relevant snippet of dmesg below would be helpful in case?
Gerald
[52145.975726] PM: Syncing filesystems ... done. [52146.328603] PM: Preparing system for mem sleep [52146.328757] Freezing user space processes ... (elapsed 0.01 seconds) done. [52146.344111] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [52146.360116] PM: Entering mem sleep [52146.360209] Suspending console(s) (use no_console_suspend to debug) [52146.516254] sd 0:0:0:0: [sda] Synchronizing SCSI cache [52146.516635] sd 0:0:0:0: [sda] Stopping disk [52146.580137] tpm_tis 00:0a: tpm_transmit: tpm_send: error -5 [52146.580145] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5 [52146.580148] PM: Device 00:0a failed to suspend: error -5 [52146.887770] PM: Some devices failed to suspend [52146.887811] sd 0:0:0:0: [sda] Starting disk [52147.376142] PM: resume of devices complete after 488.367 msecs [52147.376336] PM: Finishing wakeup. [52147.376338] Restarting tasks ... done. [52147.378718] video LNXVIDEO:00: Restoring backlight state [52148.368235] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X [52148.424106] e1000e 0000:00:19.0: irq 47 for MSI/MSI-X [52148.424409] ADDRCONF(NETDEV_UP): eth0: link is not ready [52148.454024] ADDRCONF(NETDEV_UP): wlan0: link is not ready [52151.999068] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0 [52153.309755] PM: Syncing filesystems ... done. [52153.861875] PM: Preparing system for mem sleep [52153.862037] Freezing user space processes ... (elapsed 0.03 seconds) done. [52153.892124] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [52153.908123] PM: Entering mem sleep [52153.908216] Suspending console(s) (use no_console_suspend to debug) [52154.062757] sd 0:0:0:0: [sda] Synchronizing SCSI cache [52154.063092] sd 0:0:0:0: [sda] Stopping disk [52154.120139] tpm_tis 00:0a: tpm_transmit: tpm_send: error -5 [52154.120146] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -5 [52154.120149] PM: Device 00:0a failed to suspend: error -5 [52154.439124] PM: Some devices failed to suspend [52154.439157] sd 0:0:0:0: [sda] Starting disk [52154.912092] PM: resume of devices complete after 472.963 msecs [52154.912286] PM: Finishing wakeup. [52154.912287] Restarting tasks ... done. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thursday, November 25, 2010, Jiri Kosina wrote:
On Wed, 24 Nov 2010, Gerald Pfeifer wrote:
I gave the kernel of the day (2.6.37-rc2-1.99.2.facd623-default) a spin on an up-to-date openSUSE 11.3 system and everything works like a charm, except for one thing -- suspend to RAM (or disk for that matter).
Digging into this a bit, I found that it seems to be tpm modules that cause this, and after unloading them suspend works again:
# lsmod | grep tpm tpm_tis 12002 0 tpm 17401 1 tpm_tis tpm_bios 6748 1 tpm # rmmod tpm_tis # rmmod tpm # rmmod tpm_bios # lsmod | grep tpm #
Does it make sense to file a Bugzilla for such a case, or will that be an immediate INVALID or WONTFIX?
Actually, I am seeing exactly that as well on my x200s after putting 2.6.37-rc2 there.
I am adding Rafael to CC in case it rings any bell immediately. If not, it's definitely worth upstream bugreport.
Yes, it is an upstream bug. It would be good to report it at bugzilla.kernel.org as a regression (with a CC to rjw@sisk.pl). Thanks, Rafael -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, 25 Nov 2010 21:31:45 +0100 (CET) Jiri Kosina <jkosina@suse.cz> wrote:
On Wed, 24 Nov 2010, Gerald Pfeifer wrote:
I gave the kernel of the day (2.6.37-rc2-1.99.2.facd623-default) a spin on an up-to-date openSUSE 11.3 system and everything works like a charm, except for one thing -- suspend to RAM (or disk for that matter).
Digging into this a bit, I found that it seems to be tpm modules that cause this, and after unloading them suspend works again:
# lsmod | grep tpm tpm_tis 12002 0 tpm 17401 1 tpm_tis tpm_bios 6748 1 tpm # rmmod tpm_tis # rmmod tpm # rmmod tpm_bios # lsmod | grep tpm #
Does it make sense to file a Bugzilla for such a case, or will that be an immediate INVALID or WONTFIX?
Actually, I am seeing exactly that as well on my x200s after putting 2.6.37-rc2 there.
Funny. I'm always running current Kernel:HEAD on my x200s and suspend twice a day. And - knock on wood - have not had a single suspend problem since at least 6 weeks. But I have no tpm modules loaded. Maybe I did disable the feature in the BIOS? Might have been a good idea after all :-) -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Thu, 25 Nov 2010, Jiri Kosina wrote:
I gave the kernel of the day (2.6.37-rc2-1.99.2.facd623-default) a spin on an up-to-date openSUSE 11.3 system and everything works like a charm, except for one thing -- suspend to RAM (or disk for that matter).
Digging into this a bit, I found that it seems to be tpm modules that cause this, and after unloading them suspend works again:
# lsmod | grep tpm tpm_tis 12002 0 tpm 17401 1 tpm_tis tpm_bios 6748 1 tpm # rmmod tpm_tis # rmmod tpm # rmmod tpm_bios # lsmod | grep tpm #
Does it make sense to file a Bugzilla for such a case, or will that be an immediate INVALID or WONTFIX?
Actually, I am seeing exactly that as well on my x200s after putting 2.6.37-rc2 there.
Gerald, does the problem go away if you modprobe the tpm_tis module with itpm=1 parameter? -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On 11/29/2010 09:16 AM, Jiri Kosina wrote:
On Thu, 25 Nov 2010, Jiri Kosina wrote:
I gave the kernel of the day (2.6.37-rc2-1.99.2.facd623-default) a spin on an up-to-date openSUSE 11.3 system and everything works like a charm, except for one thing -- suspend to RAM (or disk for that matter).
Digging into this a bit, I found that it seems to be tpm modules that cause this, and after unloading them suspend works again:
# lsmod | grep tpm tpm_tis 12002 0 tpm 17401 1 tpm_tis tpm_bios 6748 1 tpm # rmmod tpm_tis # rmmod tpm # rmmod tpm_bios # lsmod | grep tpm #
Does it make sense to file a Bugzilla for such a case, or will that be an immediate INVALID or WONTFIX?
Actually, I am seeing exactly that as well on my x200s after putting 2.6.37-rc2 there.
Gerald,
does the problem go away if you modprobe the tpm_tis module with
itpm=1
parameter?
There was the following on the Factory mailing list: "Am Freitag 26 November 2010 schrieb Stefan Seyfried:
On Fri, 26 Nov 2010 14:38:57 +0100
Stephan Kulow <coolo@novell.com> wrote:
Suspend is still broken on my laptop,
If it does refuse to suspend, try unloading the tpm modules. If that helps, go to the BIOS and disable the TPM chip (you are not using it anyway).
Thanks for the tip! that worked. It's called "Security chip" and it was marked as inactive, but disabling it in the BIOS helped."
Does that work for you? Larry -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Mon, 29 Nov 2010, Larry Finger wrote:
There was the following on the Factory mailing list:
"Am Freitag 26 November 2010 schrieb Stefan Seyfried:
On Fri, 26 Nov 2010 14:38:57 +0100
Stephan Kulow <coolo@novell.com> wrote:
Suspend is still broken on my laptop,
If it does refuse to suspend, try unloading the tpm modules. If that helps, go to the BIOS and disable the TPM chip (you are not using it anyway).
Thanks for the tip! that worked. It's called "Security chip" and it was marked as inactive, but disabling it in the BIOS helped."
Does that work for you?
I already know what the culprit is, and there is a patch submitted upstream to address this issue. It seems to be stalled for some reason, though. I have pinged James about it. http://lkml.org/lkml/2010/11/1/493 http://lkml.org/lkml/2010/11/29/219 -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Mon, 29 Nov 2010, Jiri Kosina wrote:
If it does refuse to suspend, try unloading the tpm modules. If that helps, go to the BIOS and disable the TPM chip (you are not using it anyway).
Thanks for the tip! that worked. It's called "Security chip" and it was marked as inactive, but disabling it in the BIOS helped."
Does that work for you?
I already know what the culprit is, and there is a patch submitted upstream to address this issue. It seems to be stalled for some reason, though. I have pinged James about it.
http://lkml.org/lkml/2010/11/1/493 http://lkml.org/lkml/2010/11/29/219
The patch is now on its way to Linus, scheduled for .37 still. It will land in our -vanilla and HEAD kernels (through upstream update) soon. -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Monday, November 29, 2010, Jiri Kosina wrote:
On Mon, 29 Nov 2010, Larry Finger wrote:
There was the following on the Factory mailing list:
"Am Freitag 26 November 2010 schrieb Stefan Seyfried:
On Fri, 26 Nov 2010 14:38:57 +0100
Stephan Kulow <coolo@novell.com> wrote:
Suspend is still broken on my laptop,
If it does refuse to suspend, try unloading the tpm modules. If that helps, go to the BIOS and disable the TPM chip (you are not using it anyway).
Thanks for the tip! that worked. It's called "Security chip" and it was marked as inactive, but disabling it in the BIOS helped."
Does that work for you?
I already know what the culprit is, and there is a patch submitted upstream to address this issue. It seems to be stalled for some reason, though. I have pinged James about it.
http://lkml.org/lkml/2010/11/1/493 http://lkml.org/lkml/2010/11/29/219
And it appears the issue is being taken care of upstream: https://lkml.org/lkml/2010/11/29/489 Rafael -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Mon, 29 Nov 2010, Jiri Kosina wrote:
does the problem go away if you modprobe the tpm_tis module with
itpm=1
parameter?
Yes, it goes away in that case or when I rmmod tpm_tis; it stay when I modprobe tpm_tis with itpm=0 or without parameter. I tested all these at least twice in arbitrary order to make sure. Gerald -- Dr. Gerald Pfeifer <gp@novell.com> Director Product Management, SUSE Linux Enterprise, openSUSE, Appliances -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, 30 Nov 2010, Gerald Pfeifer wrote:
does the problem go away if you modprobe the tpm_tis module with
itpm=1
parameter?
Yes, it goes away in that case or when I rmmod tpm_tis; it stay when I modprobe tpm_tis with itpm=0 or without parameter. I tested all these at least twice in arbitrary order to make sure.
Thanks for verifying. Just to make sure that the patch that is currently flowing into Linus' tree will work on your hardware as well, could you please look at the output of find /sys/bus/acpi/devices/ on that particular machine? If you see /sys/bus/acpi/devices/INTC0102:00 there, it'll be fixed with the referenced patch. -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, 30 Nov 2010, Jiri Kosina wrote:
Thanks for verifying. Just to make sure that the patch that is currently flowing into Linus' tree will work on your hardware as well, could you please look at the output of
find /sys/bus/acpi/devices/
on that particular machine? If you see
/sys/bus/acpi/devices/INTC0102:00
there, it'll be fixed with the referenced patch.
Yep, that's it. Looking forward to the fix in one of the next kernels of the day. :-) Thanks! Gerald -- Dr. Gerald Pfeifer <gp@novell.com> Director Product Management, SUSE Linux Enterprise, openSUSE, Appliances -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Tue, 30 Nov 2010, Gerald Pfeifer wrote:
Thanks for verifying. Just to make sure that the patch that is currently flowing into Linus' tree will work on your hardware as well, could you please look at the output of
find /sys/bus/acpi/devices/
on that particular machine? If you see
/sys/bus/acpi/devices/INTC0102:00
there, it'll be fixed with the referenced patch.
Yep, that's it. Looking forward to the fix in one of the next kernels of the day. :-)
It's there in -rc4 now. It will get synced to KOTD ftp sometime today (alternatively, you can obtain it from ftp://dist.suse.de/kerneltest/vanilla/x86_64/latest/ right away). Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2010 05:41 AM, Jiri Kosina wrote:
On Tue, 30 Nov 2010, Gerald Pfeifer wrote:
Thanks for verifying. Just to make sure that the patch that is currently flowing into Linus' tree will work on your hardware as well, could you please look at the output of
find /sys/bus/acpi/devices/
on that particular machine? If you see
/sys/bus/acpi/devices/INTC0102:00
there, it'll be fixed with the referenced patch.
Yep, that's it. Looking forward to the fix in one of the next kernels of the day. :-)
It's there in -rc4 now. It will get synced to KOTD ftp sometime today (alternatively, you can obtain it from ftp://dist.suse.de/kerneltest/vanilla/x86_64/latest/ right away).
Thanks,
Or our own kernel. It's in Kernel:HEAD now and openSUSE Factory as soon as SR 54825 is accepted. I thought I had submitted it before I left for the weekend on Thursday, but I seemed to have missed it. - -Jeff - -- Jeff Mahoney SuSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkz8Y0MACgkQLPWxlyuTD7JOSQCeP3ElaqIfZSfpDkFDr17B5JEj PU8An04BBzmTefC+f8Nd+4Qsf7B1bozV =kQKe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (7)
-
Bruno Friedmann -
Gerald Pfeifer -
Jeff Mahoney -
Jiri Kosina -
Larry Finger -
Rafael J. Wysocki -
Stefan Seyfried