3.14-rc4
by poma
$ uname -r
3.14.0-0.rc4.git0.1.fc20.x86_64
1 patch down 35 more to go.
poma
10 years, 2 months
RE: Latest kernel in F20 leads to read only file system
by Erinn Looney-Triggs
Well you get a cell picture this time. Couldn't even log in. I am using btrfs at the moment as you can see from the exception.
Erinn
-----Original Message-----
From: "Eric Sandeen" <sandeen(a)redhat.com>
Sent: 2/19/2014 20:45
To: "Erinn Looney-Triggs" <erinn.looneytriggs(a)gmail.com>; "kernel(a)lists.fedoraproject.org" <kernel(a)lists.fedoraproject.org>
Subject: Re: Latest kernel in F20 leads to read only file system
On 2/19/14, 11:19 PM, Erinn Looney-Triggs wrote:
> On 2/19/2014 6:36 PM, Eric Sandeen wrote:
>> On 2/19/14, 6:02 PM, Erinn Looney-Triggs wrote:
>>> kernel-3.13.3-201.fc20.x86_64 seems to lead to file system failures
>>> for me. Kernels < 3.13 however do not have this issue.
>>>
>>> At first I thought it was just file system corruption. However, after
>>> approximately 5 reinstalls today the issue continues to surface every
>>> time I move to the 3.13 kernel, whether using BTRFS or ext4.
>>>
>>> Behavior for both file systems differs slightly, ext4 complains about
>>> a fair number of errors (sorry I don't have the specifics)
>> We'll need those specifics. ;) dmesg and/or kernel logs in a bugzilla
>> would probably be best.
>>
>> -Eric
>>
>
> Ok given that I don't have a writeable file system, is there any reasonably smart way to go about getting these error messages to you other than writing them down and typing them up?
>
> -Erinn
You wouldn't be the first to submit a cellphone photo :)
-Eric
10 years, 2 months
Latest kernel in F20 leads to read only file system
by Erinn Looney-Triggs
kernel-3.13.3-201.fc20.x86_64 seems to lead to file system failures for
me. Kernels < 3.13 however do not have this issue.
At first I thought it was just file system corruption. However, after
approximately 5 reinstalls today the issue continues to surface every
time I move to the 3.13 kernel, whether using BTRFS or ext4.
Behavior for both file systems differs slightly, ext4 complains about a
fair number of errors (sorry I don't have the specifics) and any user is
unable to log into the system, username and password are accepted but
then it immediately return to the login prompt. BTRFS on the other hand
allows logins however, systemd-journal then starts to complain as the
file system appears to be read only.
This could of course be a hardware issue, but I reckoned I would ask
y'all first.
This is running on top of a Lenovo ThinkPad t440p laptop. Any pointers
to how to get you folks some more data would be appreciated. As I said I
have been able to consistently reproduce this issue on this system.
This may or may not be related but I have experienced corruption in the
EFI partition as well, specifically the grub.cfg file was truncated
after the last kernel upgrade, the EFI partition waas not cleanly
unmounted and the dirty bit was set thus precipitating an fsck of the
partition to repair the above issues.
Thanks,
-Erinn
10 years, 2 months
[PATCH] Build in IPMI on x86
by Matthew Garrett
The ACPI IPMI driver implements IPMI operation region support for the
ACPI core. Systems that declare ACPI operation regions may reference
them at any time, including during kernel initialisation. These accesses
will fail unless the ACPI IPMI driver is present, and undesirable system
behaviour may result. This can be avoided by building in the code rather
than leaving it as modules.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
10 years, 2 months
Enable CONFIG_PPC_DENORMALISATION in config-powerpc-generic
by Tony Breeds
Hi All,
Could we make this small change to the powerpc config.
While the scenario where I need this is on power7 the config option
isn't p7 specific.
Yours Tony
diff --git a/config-powerpc-generic b/config-powerpc-generic
index bcc30fe..9c0ad60 100644
--- a/config-powerpc-generic
+++ b/config-powerpc-generic
@@ -361,7 +361,7 @@ CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_SPAPR_TCE_IOMMU is not set
# CONFIG_TRANSPARENT_HUGEPAGE is not set
-# CONFIG_PPC_DENORMALISATION is not set
+CONFIG_PPC_DENORMALISATION=y
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_GPIO_ADNP is not set
# CONFIG_MFD_SYSCON is not set
10 years, 2 months
Koji kernel 3.13.2-200.fc20.x86_64
by bgw2007@comcast.net
I just downloaded and installed the new koji 3.13.2 kernel. I had to
roll back to 3.12.10 since the GNOME login screen would not display.
I usually download and install new koji kernels to provide karna for
updates. This is probably the first time for me that seemingly won't
start GNOME.
--
Brad Watson
MailTo:watsonbrad@comcast.net
WWW: http://brad.bradwatson.net/
10 years, 2 months
WARNING: CPU: 2 PID: 4415 at lib/idr.c:527 idr_remove.part.6+0x243/0x250()
by poma
Ahoy!
My trace is the last one, therefore per LIFO I am sending this report to
you.
------------[ cut here ]------------
WARNING: CPU: 2 PID: 4415 at lib/idr.c:527 idr_remove.part.6+0x243/0x250()
idr_remove called for id=136 which is not allocated.
CPU: 2 PID: 4415 Comm: systemd Not tainted 3.12.10-300.fc20.x86_64 #1
Call Trace:
[<ffffffff81667ed5>] dump_stack+0x45/0x56
[<ffffffff8106903d>] warn_slowpath_common+0x7d/0xa0
[<ffffffff810690ac>] warn_slowpath_fmt+0x4c/0x50
[<ffffffff81304073>] idr_remove.part.6+0x243/0x250
[<ffffffff811c458c>] ? d_walk+0xdc/0x2a0
[<ffffffff8130408d>] idr_remove+0xd/0x10
[<ffffffff810defa6>] cgroup_destroy_css_killed+0x46/0x70
[<ffffffff810e1c98>] cgroup_destroy_locked+0x2d8/0x310
[<ffffffff810e1cf2>] cgroup_rmdir+0x22/0x40
[<ffffffff811bc108>] vfs_rmdir+0xa8/0x100
[<ffffffff811bc2dd>] do_rmdir+0x17d/0x1d0
[<ffffffff81087b6c>] ? task_work_run+0xac/0xe0
[<ffffffff81012a21>] ? do_notify_resume+0x61/0xa0
[<ffffffff811bf616>] SyS_rmdir+0x16/0x20
[<ffffffff81676ea9>] system_call_fastpath+0x16/0x1b
---[ end trace 4ebc2893b27b190d ]---
There are a bunch of here:
https://bugzilla.redhat.com/show_bug.cgi?id=1045755
Thanks.
poma
10 years, 2 months