[arch-general] linux-3.5.x status
Hi guys, 3.5.x is not yet ready to move to [core], - ext4 regression is not fixed yet, will be fixed in 3.5.3 - watchdogs are completely broken I'm not sure how much of a showstopper the watchdogs are, so please shout out if this is a real problem. If you have any other showstopper please let me know. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Donnerstag, den 23.08.2012, 16:10 +0200 schrieb Tobias Powalowski:
Hi guys,
3.5.x is not yet ready to move to [core], - ext4 regression is not fixed yet, will be fixed in 3.5.3 - watchdogs are completely broken I'm not sure how much of a showstopper the watchdogs are, so please shout out if this is a real problem. If you have any other showstopper please let me know.
On my Dell Latitude D410, it crashes on boot: http://pastie.org/4575177 The graphics-chip is a "Intel 915GM/GMS/910GML". regards Bjoern -- xmpp: bjo@schafweide.org bjo.nord-west.org | nord-west.org | freifunk-ol.de
Am 23.08.2012 18:10, schrieb Bjoern Franke:
Am Donnerstag, den 23.08.2012, 16:10 +0200 schrieb Tobias Powalowski:
Hi guys,
3.5.x is not yet ready to move to [core], - ext4 regression is not fixed yet, will be fixed in 3.5.3 - watchdogs are completely broken I'm not sure how much of a showstopper the watchdogs are, so please shout out if this is a real problem. If you have any other showstopper please let me know.
On my Dell Latitude D410, it crashes on boot: http://pastie.org/4575177
The graphics-chip is a "Intel 915GM/GMS/910GML".
I don't think we will block the move to core on an isolated hardware crash that affects only a single user. Still, can you give us the link to the kernel bugzilla report for this crash?
I don't think we will block the move to core on an isolated hardware crash that affects only a single user.
Sure.
Still, can you give us the link to the kernel bugzilla report for this crash?
https://bugzilla.kernel.org/show_bug.cgi?id=46381 -- xmpp: bjo@schafweide.org bjo.nord-west.org | nord-west.org | freifunk-ol.de
Am 23.08.2012 18:52, schrieb Bjoern Franke:
I don't think we will block the move to core on an isolated hardware crash that affects only a single user.
Sure.
Still, can you give us the link to the kernel bugzilla report for this crash?
That was quick. We should probably add [1] to our 3.5.3 kernel as well, if it isn't int he stable kernel already. According to the bug report, this will fix your problem. [1] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=cee...
Hi,
We should probably add [1] to our 3.5.3 kernel as well, if it isn't int he stable kernel already. According to the bug report, this will fix your problem.
This would be nice. Yes, the issue seems to be fixed in 3.6rc3, it doesn't appear on my laptop. regards Bjoern -- xmpp: bjo@schafweide.org bjo.nord-west.org | nord-west.org | freifunk-ol.de
On Thu, Aug 23, 2012 at 16:10:26 +0200, Tobias Powalowski wrote:
Hi guys,
3.5.x is not yet ready to move to [core], - ext4 regression is not fixed yet, will be fixed in 3.5.3 - watchdogs are completely broken I'm not sure how much of a showstopper the watchdogs are, so please shout out if this is a real problem. If you have any other showstopper please let me know.
Since upgrading to 3.5.x, my system with mdraid mirror boots with either a degraded RAID array, or not auto-discovering the RAID at all. The disks are fine, confirmed by both SMART selftest and badblocks scan. Downgraded back to 3.4.9 and the problem went away. Anyone else experienced this? My setup should be common, with /boot on /dev/md0 over sda1+sdb1, and the rest on LVM on /dev/md1 over sda2+sdb2. Geert -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
Am 23.08.2012 18:29, schrieb Geert Hendrickx:
Since upgrading to 3.5.x, my system with mdraid mirror boots with either a degraded RAID array, or not auto-discovering the RAID at all.
The disks are fine, confirmed by both SMART selftest and badblocks scan. Downgraded back to 3.4.9 and the problem went away.
Anyone else experienced this? My setup should be common, with /boot on /dev/md0 over sda1+sdb1, and the rest on LVM on /dev/md1 over sda2+sdb2.
At home, I have sda1+sdb1 on md0 and sda4+sdb4 on md1, and I don't see any problems.
I have another problem - on my atom 570 kvm causes qemu to segfault.
On Thu, Aug 23, 2012 at 18:34:18 +0200, Thomas Bächler wrote:
Am 23.08.2012 18:29, schrieb Geert Hendrickx:
Since upgrading to 3.5.x, my system with mdraid mirror boots with either a degraded RAID array, or not auto-discovering the RAID at all.
The disks are fine, confirmed by both SMART selftest and badblocks scan. Downgraded back to 3.4.9 and the problem went away.
Anyone else experienced this? My setup should be common, with /boot on /dev/md0 over sda1+sdb1, and the rest on LVM on /dev/md1 over sda2+sdb2.
At home, I have sda1+sdb1 on md0 and sda4+sdb4 on md1, and I don't see any problems.
For me it's still very much reproducible though, with either 3.5.2 or 3.5.3. Geert -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
Am 27.08.2012 17:50, schrieb Geert Hendrickx:
On Thu, Aug 23, 2012 at 18:34:18 +0200, Thomas Bächler wrote:
Am 23.08.2012 18:29, schrieb Geert Hendrickx:
Since upgrading to 3.5.x, my system with mdraid mirror boots with either a degraded RAID array, or not auto-discovering the RAID at all.
The disks are fine, confirmed by both SMART selftest and badblocks scan. Downgraded back to 3.4.9 and the problem went away.
Anyone else experienced this? My setup should be common, with /boot on /dev/md0 over sda1+sdb1, and the rest on LVM on /dev/md1 over sda2+sdb2.
At home, I have sda1+sdb1 on md0 and sda4+sdb4 on md1, and I don't see any problems.
For me it's still very much reproducible though, with either 3.5.2 or 3.5.3.
Can you run add 'break=premount' to the kernel command line and try to get some mdadm output? I don't know exactly what to look for, but maybe try to assemble the array with verbose output. By using break=premount, you hook into the boot process _before_ anything has been written to your disk, so you don't destroy the consistency of your RAID. Also, can we see your mdadm.conf? Which mdadm hook are you using, mdadm or mdadm_udev (I use mdadm_udev btw)?
On Mon, Aug 27, 2012 at 18:06:05 +0200, Thomas Bächler wrote:
Can you run add 'break=premount' to the kernel command line and try to get some mdadm output? I don't know exactly what to look for, but maybe try to assemble the array with verbose output. By using break=premount, you hook into the boot process _before_ anything has been written to your disk, so you don't destroy the consistency of your RAID.
Also, can we see your mdadm.conf? Which mdadm hook are you using, mdadm or mdadm_udev (I use mdadm_udev btw)?
break=premount breaks after RAID+LVM assembly, so doesn't really help. :-) But I get dropped to a shell prompt anyway when the raid can't be assembled. I forgot to mention, "mdassemble" always works fine from there (no "mdadm" command in the initrd). Could it be a timing related issue/race condition? My mdadm.conf is attached. I don't know whether that uses mdad_udev or not? Geert -- geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
Am 27.08.2012 18:41, schrieb Geert Hendrickx:
On Mon, Aug 27, 2012 at 18:06:05 +0200, Thomas Bächler wrote:
Can you run add 'break=premount' to the kernel command line and try to get some mdadm output? I don't know exactly what to look for, but maybe try to assemble the array with verbose output. By using break=premount, you hook into the boot process _before_ anything has been written to your disk, so you don't destroy the consistency of your RAID.
Also, can we see your mdadm.conf? Which mdadm hook are you using, mdadm or mdadm_udev (I use mdadm_udev btw)?
break=premount breaks after RAID+LVM assembly, so doesn't really help. :-)
But I get dropped to a shell prompt anyway when the raid can't be assembled. I forgot to mention, "mdassemble" always works fine from there (no "mdadm" command in the initrd). Could it be a timing related issue/race condition?
My mdadm.conf is attached. I don't know whether that uses mdad_udev or not?
/etc/mkinitcpio.conf tells you :)
Am 23.08.2012 16:10, schrieb Tobias Powalowski:
Hi guys,
3.5.x is not yet ready to move to [core], - ext4 regression is not fixed yet, will be fixed in 3.5.3 - watchdogs are completely broken I'm not sure how much of a showstopper the watchdogs are, so please shout out if this is a real problem. If you have any other showstopper please let me know.
greetings tpowa Ok everything reported fixed. Please signoff and 3.5.3 will move to core.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Thu, Aug 23, 2012 at 04:10:26PM +0200, Tobias Powalowski wrote:
If you have any other showstopper please let me know.
I just upgraded my machine to the new kernel this morning, and was greeted by a kernel panic coming out of the shower. Unfortunately, nothing was logged to the disk, so I have nothing to share here, which probably makes this email near useless. However, it is worth noting that after forcing the system down and powering it on again, I was greeted with "MACHINE CHECK ERROR" after the BIOS splash, followed by a boot cycle which would again stop at this point. After turning the machine off again for a while, I powered it on with no difficulty and was able to boot into arch. Any input would be greatly appreciated. pants.
On Tue, Aug 28, 2012 at 1:55 PM, pants <pants@cs.hmc.edu> wrote:
I just upgraded my machine to the new kernel this morning, and was greeted by a kernel panic coming out of the shower. Unfortunately, nothing was logged to the disk, so I have nothing to share here, which probably makes this email near useless.
However, it is worth noting that after forcing the system down and powering it on again, I was greeted with "MACHINE CHECK ERROR" after the BIOS splash, followed by a boot cycle which would again stop at this point. After turning the machine off again for a while, I powered it on with no difficulty and was able to boot into arch.
Any input would be greatly appreciated.
I'm no kernel dev, but that sounds like a hardware issue to me. =-Jameson
participants (7)
-
Bjoern Franke
-
Geert Hendrickx
-
Jameson
-
Michal Kawalec
-
pants
-
Thomas Bächler
-
Tobias Powalowski