RE: [BISECTED] 3.19-rc1 regression - kernel does not load in GRUB 0.97 (GRUB Legacy)
> -Original Message- > From: Пламен Петров [mailto:pla...@petrovi.no-ip.info] > Sent: Sunday, December 28, 2014 9:20 AM > To: 'Juergen Gross'; 'linux-kernel@vger.kernel.org' > Cc: 'Thomas Gleixner' > Subject: RE: [BISECTED] 3.19-rc1 regression - kernel does not load in GRUB > 0.97 (GRUB Legacy) > > > -Original Message- > > From: Juergen Gross [mailto:jgr...@suse.com] > > Sent: Saturday, December 27, 2014 3:48 PM > > To: Пламен Петров; linux-kernel@vger.kernel.org > > Cc: 'Thomas Gleixner' > > Subject: Re: [BISECTED] 3.19-rc1 regression - kernel does not load in > > GRUB > > 0.97 (GRUB Legacy) > > ... > > > > Can you boot with kernel option "nopat"? > > Same as above - kernel command line options do not help, as they never get > into play to even make a difference. > Scratch the above, and sorry for my jump to conclusions instead of "First Trying"T. Adding "nopat" to the kernel command line options does make the previously broken unpatched vanilla 3.19-rc1 kernel boot fine. Does this mean that I should add "nopat" command line option to all VMs for 3.19? > If you need the actual details of my setup or want me to try patches - just > ask. > - Plamen Petrov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BISECTED] 3.19-rc1 regression - kernel does not load in GRUB 0.97 (GRUB Legacy)
> -Original Message- > From: Juergen Gross [mailto:jgr...@suse.com] > Sent: Saturday, December 27, 2014 3:48 PM > To: Пламен Петров; linux-kernel@vger.kernel.org > Cc: 'Thomas Gleixner' > Subject: Re: [BISECTED] 3.19-rc1 regression - kernel does not load in GRUB > 0.97 (GRUB Legacy) > > On 12/24/2014 01:28 AM, Пламен Петров wrote: > > Hello! > > > > I use GRUB Legacy bootloader (version 0.97) on a couple machines, and > > where 3.18.x loads fine, 3.19-rc1 does not. > > > > While compiling I used the attached .config file accompanied by "make > > olddefconfig" > > Can you tell me something about the hardware (processor model)? > You are not booting the system under VMWare by any chance? As a matter of fact - I am compiling in a VMware Player (6.0.3 build-1895310) virtual machine, boot testing there, and then if everything is OK, I transfer the monolithic kernel produced on 3 virtual machines that run on EXSi and 2 actual servers. So along those lines - the failing 3.19-rc1 never saw actual hardware - it was all tested (and bisected) inside a VM. > > Could you try the earlyprintk kernel option (serial or vga)? Does not help. You see - the kernel never makes it there to print anything. GRUB just says: kernel /vmlinuz.test rw root=/dev/sda2 console=ttyS0,9600n8 console=tty0 [Linux-bzImage, setup=0x3c00, size=0x430ec0] early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel. and it just stays there. Retyping the above here got me thinking - is early console part of the kernel? > > Can you boot with kernel option "nopat"? Same as above - kernel command line options do not help, as they never get into play to even make a difference. If you need the actual details of my setup or want me to try patches - just ask. > > Juergen > > > The bisection I ran points to: > > bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 is the first bad commit > > commit bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 > > Author: Juergen Gross > > Date: Mon Nov 3 14:02:03 2014 +0100 > > > > x86: Enable PAT to use cache mode translation tables > > Anyway, thanks to all the devs for their changes in 3.19-rc1 - there is a huge difference in loading speed in my compile VM: with 3.18.x there is something like 60 seconds until the VM is up and running; and with 3.19-rc1 (with commit bd809af16e3ab1f8d55b3e2928c4 reverted) - that same machine is up and running in less than 10 seconds. So that makes it a 6-fold loading time speedup from just going to 3.19-rc1. Thanks! - Plamen Petrov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BISECTED] 3.19-rc1 regression - kernel does not load in GRUB 0.97 (GRUB Legacy)
-Original Message- From: Juergen Gross [mailto:jgr...@suse.com] Sent: Saturday, December 27, 2014 3:48 PM To: Пламен Петров; linux-kernel@vger.kernel.org Cc: 'Thomas Gleixner' Subject: Re: [BISECTED] 3.19-rc1 regression - kernel does not load in GRUB 0.97 (GRUB Legacy) On 12/24/2014 01:28 AM, Пламен Петров wrote: Hello! I use GRUB Legacy bootloader (version 0.97) on a couple machines, and where 3.18.x loads fine, 3.19-rc1 does not. While compiling I used the attached .config file accompanied by make olddefconfig Can you tell me something about the hardware (processor model)? You are not booting the system under VMWare by any chance? As a matter of fact - I am compiling in a VMware Player (6.0.3 build-1895310) virtual machine, boot testing there, and then if everything is OK, I transfer the monolithic kernel produced on 3 virtual machines that run on EXSi and 2 actual servers. So along those lines - the failing 3.19-rc1 never saw actual hardware - it was all tested (and bisected) inside a VM. Could you try the earlyprintk kernel option (serial or vga)? Does not help. You see - the kernel never makes it there to print anything. GRUB just says: kernel /vmlinuz.test rw root=/dev/sda2 console=ttyS0,9600n8 console=tty0 [Linux-bzImage, setup=0x3c00, size=0x430ec0] early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel. and it just stays there. Retyping the above here got me thinking - is early console part of the kernel? Can you boot with kernel option nopat? Same as above - kernel command line options do not help, as they never get into play to even make a difference. If you need the actual details of my setup or want me to try patches - just ask. Juergen The bisection I ran points to: bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 is the first bad commit commit bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 Author: Juergen Gross jgr...@suse.com Date: Mon Nov 3 14:02:03 2014 +0100 x86: Enable PAT to use cache mode translation tables Anyway, thanks to all the devs for their changes in 3.19-rc1 - there is a huge difference in loading speed in my compile VM: with 3.18.x there is something like 60 seconds until the VM is up and running; and with 3.19-rc1 (with commit bd809af16e3ab1f8d55b3e2928c4 reverted) - that same machine is up and running in less than 10 seconds. So that makes it a 6-fold loading time speedup from just going to 3.19-rc1. Thanks! - Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [BISECTED] 3.19-rc1 regression - kernel does not load in GRUB 0.97 (GRUB Legacy)
-Original Message- From: Пламен Петров [mailto:pla...@petrovi.no-ip.info] Sent: Sunday, December 28, 2014 9:20 AM To: 'Juergen Gross'; 'linux-kernel@vger.kernel.org' Cc: 'Thomas Gleixner' Subject: RE: [BISECTED] 3.19-rc1 regression - kernel does not load in GRUB 0.97 (GRUB Legacy) -Original Message- From: Juergen Gross [mailto:jgr...@suse.com] Sent: Saturday, December 27, 2014 3:48 PM To: Пламен Петров; linux-kernel@vger.kernel.org Cc: 'Thomas Gleixner' Subject: Re: [BISECTED] 3.19-rc1 regression - kernel does not load in GRUB 0.97 (GRUB Legacy) ... Can you boot with kernel option nopat? Same as above - kernel command line options do not help, as they never get into play to even make a difference. Scratch the above, and sorry for my jump to conclusions instead of First TryingT. Adding nopat to the kernel command line options does make the previously broken unpatched vanilla 3.19-rc1 kernel boot fine. Does this mean that I should add nopat command line option to all VMs for 3.19? If you need the actual details of my setup or want me to try patches - just ask. - Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BISECTED] 3.19-rc1 regression - kernel does not load in GRUB 0.97 (GRUB Legacy)
Hello! I use GRUB Legacy bootloader (version 0.97) on a couple machines, and where 3.18.x loads fine, 3.19-rc1 does not. While compiling I used the attached .config file accompanied by "make olddefconfig" The bisection I ran points to: bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 is the first bad commit commit bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 Author: Juergen Gross Date: Mon Nov 3 14:02:03 2014 +0100 x86: Enable PAT to use cache mode translation tables Update the translation tables from cache mode to pgprot values according to the PAT settings. This enables changing the cache attributes of a PAT index in just one place without having to change at the users side. With this change it is possible to use the same kernel with different PAT configurations, e.g. supporting Xen. Here is the output of git bisect log git bisect start # bad: [97bf6af1f928216fd6c5a66e8a57bfa95a659672] Linux 3.19-rc1 git bisect bad 97bf6af1f928216fd6c5a66e8a57bfa95a659672 # good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18 git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d # bad: [70e71ca0af244f48a5dcf56dc435243792e3a495] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect bad 70e71ca0af244f48a5dcf56dc435243792e3a495 # bad: [e28870f9b3e92cd3570925089c6bb789c2603bc4] Merge tag 'backlight-for-linus-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight git bisect bad e28870f9b3e92cd3570925089c6bb789c2603bc4 # good: [6da314122ddc11936c6f054753bbb956a499d020] Merge tag 'dt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good 6da314122ddc11936c6f054753bbb956a499d020 # good: [a53b831549141aa060a8b54b76e3a42870d74cc0] exit: pidns: fix/update the comments in zap_pid_ns_processes() git bisect good a53b831549141aa060a8b54b76e3a42870d74cc0 # bad: [cbfe0de303a55ed96d8831c2d5f56f8131cd6612] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect bad cbfe0de303a55ed96d8831c2d5f56f8131cd6612 # bad: [a6b849578ef3e0b131b1ea4063473a4f935a65e9] Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6 git bisect bad a6b849578ef3e0b131b1ea4063473a4f935a65e9 # bad: [c9f861c77269bc9950c16c6404a9476062241671] Merge branch 'x86-ras-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad c9f861c77269bc9950c16c6404a9476062241671 # good: [773fed910d41e443e495a6bfa9ab1c2b7b13e012] Merge branches 'x86-platform-for-linus' and 'x86-uv-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 773fed910d41e443e495a6bfa9ab1c2b7b13e012 # good: [f439c429c320981943f8b64b2a4049d946cb492b] x86: Support PAT bit in pagetable dump for lower levels git bisect good f439c429c320981943f8b64b2a4049d946cb492b # good: [e3480271f59253cb60d030aa5e615bf00b731fea] x86, mce, severity: Extend the the mce_severity mechanism to handle UCNA/DEFERRED error git bisect good e3480271f59253cb60d030aa5e615bf00b731fea # bad: [0dbcae884779fdf7e2239a97ac7488877f0693d9] x86: mm: Move PAT only functions to mm/pat.c git bisect bad 0dbcae884779fdf7e2239a97ac7488877f0693d9 # bad: [bd809af16e3ab1f8d55b3e2928c47c67e2a865d2] x86: Enable PAT to use cache mode translation tables git bisect bad bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 # good: [f5b2831d654167d77da8afbef4d2584897b12d0c] x86: Respect PAT bit when copying pte values between large and normal pages git bisect good f5b2831d654167d77da8afbef4d2584897b12d0c # first bad commit: [bd809af16e3ab1f8d55b3e2928c47c67e2a865d2] x86: Enable PAT to use cache mode translation tables Reverting the above commit fixes the problem for me, and 3.19-rc1 loads fine. Any additional info available on request. Please, CC me - I am not subscribed to the list. - Plamen Petrov config-v3.19-rc1-12-g443fb5a Description: Binary data
[BISECTED] 3.19-rc1 regression - kernel does not load in GRUB 0.97 (GRUB Legacy)
Hello! I use GRUB Legacy bootloader (version 0.97) on a couple machines, and where 3.18.x loads fine, 3.19-rc1 does not. While compiling I used the attached .config file accompanied by make olddefconfig The bisection I ran points to: bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 is the first bad commit commit bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 Author: Juergen Gross jgr...@suse.com Date: Mon Nov 3 14:02:03 2014 +0100 x86: Enable PAT to use cache mode translation tables Update the translation tables from cache mode to pgprot values according to the PAT settings. This enables changing the cache attributes of a PAT index in just one place without having to change at the users side. With this change it is possible to use the same kernel with different PAT configurations, e.g. supporting Xen. Here is the output of git bisect log git bisect start # bad: [97bf6af1f928216fd6c5a66e8a57bfa95a659672] Linux 3.19-rc1 git bisect bad 97bf6af1f928216fd6c5a66e8a57bfa95a659672 # good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18 git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d # bad: [70e71ca0af244f48a5dcf56dc435243792e3a495] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect bad 70e71ca0af244f48a5dcf56dc435243792e3a495 # bad: [e28870f9b3e92cd3570925089c6bb789c2603bc4] Merge tag 'backlight-for-linus-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight git bisect bad e28870f9b3e92cd3570925089c6bb789c2603bc4 # good: [6da314122ddc11936c6f054753bbb956a499d020] Merge tag 'dt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good 6da314122ddc11936c6f054753bbb956a499d020 # good: [a53b831549141aa060a8b54b76e3a42870d74cc0] exit: pidns: fix/update the comments in zap_pid_ns_processes() git bisect good a53b831549141aa060a8b54b76e3a42870d74cc0 # bad: [cbfe0de303a55ed96d8831c2d5f56f8131cd6612] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect bad cbfe0de303a55ed96d8831c2d5f56f8131cd6612 # bad: [a6b849578ef3e0b131b1ea4063473a4f935a65e9] Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6 git bisect bad a6b849578ef3e0b131b1ea4063473a4f935a65e9 # bad: [c9f861c77269bc9950c16c6404a9476062241671] Merge branch 'x86-ras-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad c9f861c77269bc9950c16c6404a9476062241671 # good: [773fed910d41e443e495a6bfa9ab1c2b7b13e012] Merge branches 'x86-platform-for-linus' and 'x86-uv-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 773fed910d41e443e495a6bfa9ab1c2b7b13e012 # good: [f439c429c320981943f8b64b2a4049d946cb492b] x86: Support PAT bit in pagetable dump for lower levels git bisect good f439c429c320981943f8b64b2a4049d946cb492b # good: [e3480271f59253cb60d030aa5e615bf00b731fea] x86, mce, severity: Extend the the mce_severity mechanism to handle UCNA/DEFERRED error git bisect good e3480271f59253cb60d030aa5e615bf00b731fea # bad: [0dbcae884779fdf7e2239a97ac7488877f0693d9] x86: mm: Move PAT only functions to mm/pat.c git bisect bad 0dbcae884779fdf7e2239a97ac7488877f0693d9 # bad: [bd809af16e3ab1f8d55b3e2928c47c67e2a865d2] x86: Enable PAT to use cache mode translation tables git bisect bad bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 # good: [f5b2831d654167d77da8afbef4d2584897b12d0c] x86: Respect PAT bit when copying pte values between large and normal pages git bisect good f5b2831d654167d77da8afbef4d2584897b12d0c # first bad commit: [bd809af16e3ab1f8d55b3e2928c47c67e2a865d2] x86: Enable PAT to use cache mode translation tables Reverting the above commit fixes the problem for me, and 3.19-rc1 loads fine. Any additional info available on request. Please, CC me - I am not subscribed to the list. - Plamen Petrov config-v3.19-rc1-12-g443fb5a Description: Binary data
Re: [PATCH] do_mounts: try all available filesystems before panicking
2014-05-26 7:19 GMT+03:00 Dave Chinner : > On Mon, May 26, 2014 at 11:19:04AM +1000, Dave Chinner wrote: >> On Mon, May 26, 2014 at 10:08:13AM +1000, Dave Chinner wrote: >> > On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote: >> > > On Mon, May 5, 2014 at 11:34 AM, Plamen Petrov >> > > wrote: >> > > > >> > > > The story short: on systems with btrfs root I have a kernel .config >> > > > with ext4, >> > > > xfs and btrfs built-in which works fine with 3.13.x, but 3.14.x >> > > > panics. After >> > > > inserting some debug printks, I got this info from mount_block_root: >> > > > >> > > > ---> EACCESS=13, EINVAL=22, Available filesystems: ext3 ext2 ext4 >> > > > fuseblk xfs btrfs >> > > > -> Tried ext3, error code is -22. >> > > > -> Tried ext2, error code is -22. >> > > > -> Tried ext4, error code is -22. >> > > > -> Tried fuseblk, error code is -22. >> > > > -> Tried xfs, error code is -38. >> > > > VFS: Cannot open root device "sda2" or unknown-block(8,2): error -38 >> > > > Please append a correct "root=" boot option; here are the available >> > > > partitions: >> >> BTW, This is the original thread with lots of triage in it: >> >> http://www.spinics.net/lists/linux-btrfs/msg33455.html >> >> But that doesn't reach any conclusion. I suspect that the >> change of btrfs init (from very early (@~1.8s into the boot) until a >> few milliseconds before the root mount is changing the order in >> which the filesystem type list is traversed by the mount, resulting >> in XFS being used to probe the device before btrfs. > > On that point, on 3.15-rc6: > > $ tail -1 /proc/filesystems > btrfs > $ > >> Why XFS is seeing /dev/sda2 as containing an XFS filesystem is not >> yet clear, but perhaps once you've dumped the the first sector of >> the btrfs partition all will become clear > > No need, I found the regression. Plamen, can you please try the > patch below? > Yes, Dave. I applied your patch on top of linux 3.15-rc5. I tried the patch you sent in a VM I used for tests. With only your patch applied - the system boots up normally. Thanks for the different perspectives, guys! Always a pleasure communicating with you. After a month or so waiting - definetly worth it! Thanks a lot! -- Plamen Petrov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] do_mounts: try all available filesystems before panicking
2014-05-26 7:19 GMT+03:00 Dave Chinner da...@fromorbit.com: On Mon, May 26, 2014 at 11:19:04AM +1000, Dave Chinner wrote: On Mon, May 26, 2014 at 10:08:13AM +1000, Dave Chinner wrote: On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote: On Mon, May 5, 2014 at 11:34 AM, Plamen Petrov plamen.s...@gmail.com wrote: The story short: on systems with btrfs root I have a kernel .config with ext4, xfs and btrfs built-in which works fine with 3.13.x, but 3.14.x panics. After inserting some debug printks, I got this info from mount_block_root: --- EACCESS=13, EINVAL=22, Available filesystems: ext3 ext2 ext4 fuseblk xfs btrfs - Tried ext3, error code is -22. - Tried ext2, error code is -22. - Tried ext4, error code is -22. - Tried fuseblk, error code is -22. - Tried xfs, error code is -38. VFS: Cannot open root device sda2 or unknown-block(8,2): error -38 Please append a correct root= boot option; here are the available partitions: BTW, This is the original thread with lots of triage in it: http://www.spinics.net/lists/linux-btrfs/msg33455.html But that doesn't reach any conclusion. I suspect that the change of btrfs init (from very early (@~1.8s into the boot) until a few milliseconds before the root mount is changing the order in which the filesystem type list is traversed by the mount, resulting in XFS being used to probe the device before btrfs. On that point, on 3.15-rc6: $ tail -1 /proc/filesystems btrfs $ Why XFS is seeing /dev/sda2 as containing an XFS filesystem is not yet clear, but perhaps once you've dumped the the first sector of the btrfs partition all will become clear No need, I found the regression. Plamen, can you please try the patch below? Yes, Dave. I applied your patch on top of linux 3.15-rc5. I tried the patch you sent in a VM I used for tests. With only your patch applied - the system boots up normally. Thanks for the different perspectives, guys! Always a pleasure communicating with you. After a month or so waiting - definetly worth it! Thanks a lot! -- Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] do_mounts: fix not all available filesystems get tried during boot
XFS, for one. Best see the mentioned bugzilla entries. 2014-04-27 14:04 GMT+03:00 Richard Weinberger : > On Sun, Apr 27, 2014 at 12:37 PM, Пламен Петров wrote: >> While debugging a kernel panic with 3.14.1 it became clear that some >> changes made some filesystems mount routines return error codes other >> than 0, EACCES and EINVAL. Such return codes result in the kernel >> panicking without trying to mount root with all of the available >> filesystems, as can be seen in bugzilla entries 74901 and 74261. > > What filesystems are these? > >> Make mount_block_root continue trying other available filesystems by >> default, not only when the last tried returned EACCES or EINVAL. >> >> Signed-off-by: Plamen Petrov >> --- >> init/do_mounts.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/init/do_mounts.c b/init/do_mounts.c >> index 09ded58..a4abbdf 100644 >> --- a/init/do_mounts.c >> +++ b/init/do_mounts.c >> @@ -403,7 +403,7 @@ retry: >> case -EACCES: >> flags |= MS_RDONLY; >> goto retry; >> - case -EINVAL: >> + default: >> continue; >> } >> /* >> -- >> 1.9.0 >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ > > > > -- > Thanks, > //richard -- Plamen Petrov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] do_mounts: fix not all available filesystems get tried during boot
While debugging a kernel panic with 3.14.1 it became clear that some changes made some filesystems mount routines return error codes other than 0, EACCES and EINVAL. Such return codes result in the kernel panicking without trying to mount root with all of the available filesystems, as can be seen in bugzilla entries 74901 and 74261. Make mount_block_root continue trying other available filesystems by default, not only when the last tried returned EACCES or EINVAL. Signed-off-by: Plamen Petrov --- init/do_mounts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/do_mounts.c b/init/do_mounts.c index 09ded58..a4abbdf 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -403,7 +403,7 @@ retry: case -EACCES: flags |= MS_RDONLY; goto retry; - case -EINVAL: + default: continue; } /* -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] do_mounts: fix not all available filesystems get tried during boot
While debugging a kernel panic with 3.14.1 it became clear that some changes made some filesystems mount routines return error codes other than 0, EACCES and EINVAL. Such return codes result in the kernel panicking without trying to mount root with all of the available filesystems, as can be seen in bugzilla entries 74901 and 74261. Make mount_block_root continue trying other available filesystems by default, not only when the last tried returned EACCES or EINVAL. Signed-off-by: Plamen Petrov plamen.s...@gmail.com --- init/do_mounts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/do_mounts.c b/init/do_mounts.c index 09ded58..a4abbdf 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -403,7 +403,7 @@ retry: case -EACCES: flags |= MS_RDONLY; goto retry; - case -EINVAL: + default: continue; } /* -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] do_mounts: fix not all available filesystems get tried during boot
XFS, for one. Best see the mentioned bugzilla entries. 2014-04-27 14:04 GMT+03:00 Richard Weinberger richard.weinber...@gmail.com: On Sun, Apr 27, 2014 at 12:37 PM, Пламен Петров plamen.s...@gmail.com wrote: While debugging a kernel panic with 3.14.1 it became clear that some changes made some filesystems mount routines return error codes other than 0, EACCES and EINVAL. Such return codes result in the kernel panicking without trying to mount root with all of the available filesystems, as can be seen in bugzilla entries 74901 and 74261. What filesystems are these? Make mount_block_root continue trying other available filesystems by default, not only when the last tried returned EACCES or EINVAL. Signed-off-by: Plamen Petrov plamen.s...@gmail.com --- init/do_mounts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/do_mounts.c b/init/do_mounts.c index 09ded58..a4abbdf 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -403,7 +403,7 @@ retry: case -EACCES: flags |= MS_RDONLY; goto retry; - case -EINVAL: + default: continue; } /* -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Thanks, //richard -- Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel panic during boot - 3.14.1, root is btrfs
Hello! I was trying to move several systems which have their root formatted as btrfs from 3.13.x to 3.14.x and the kernel panicked during boot. Is there anything special that needs to be done as to prepare an in-use-btrfs-root for kernel >=3.14 ? I bisected the problem to a btrfs commit, although I'm not entirely sure its 100% correct. The systems are one physical machine and a couple of virtual ones. Since I bisected this the physical one was converted to XFS root - it's a production machine with real users. More details on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74261 Greg KH says that 3.13.11 will be the last of the series, and advises to move on to 3.14.x - but currently that is impossible for me (bar converting the root to different FS). Can someone think of something to help this situation? P.S. Please, CC me as I'm not subscribed to the kernel mailing list. - Plamen Petrov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel panic during boot - 3.14.1, root is btrfs
Hello! I was trying to move several systems which have their root formatted as btrfs from 3.13.x to 3.14.x and the kernel panicked during boot. Is there anything special that needs to be done as to prepare an in-use-btrfs-root for kernel =3.14 ? I bisected the problem to a btrfs commit, although I'm not entirely sure its 100% correct. The systems are one physical machine and a couple of virtual ones. Since I bisected this the physical one was converted to XFS root - it's a production machine with real users. More details on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74261 Greg KH says that 3.13.11 will be the last of the series, and advises to move on to 3.14.x - but currently that is impossible for me (bar converting the root to different FS). Can someone think of something to help this situation? P.S. Please, CC me as I'm not subscribed to the kernel mailing list. - Plamen Petrov -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
