recvmsg bug not clear
Most users won't even know what string from this to google on to find out what this is all about: Jul 03 13:57:20 jidanni7 kernel: [ cut here ] Jul 03 13:57:20 jidanni7 kernel: recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0 Jul 03 13:57:20 jidanni7 kernel: WARNING: CPU: 2 PID: 1501 at /build/linux-uwVqDp/linux-4.16.16/net/ipv4/tcp.c:1881 tcp_recvmsg+0x649/0xb90 Jul 03 13:57:20 jidanni7 kernel: Modules linked in: nft_r... So please make clearer messages.
recvmsg bug not clear
Most users won't even know what string from this to google on to find out what this is all about: Jul 03 13:57:20 jidanni7 kernel: [ cut here ] Jul 03 13:57:20 jidanni7 kernel: recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0 Jul 03 13:57:20 jidanni7 kernel: WARNING: CPU: 2 PID: 1501 at /build/linux-uwVqDp/linux-4.16.16/net/ipv4/tcp.c:1881 tcp_recvmsg+0x649/0xb90 Jul 03 13:57:20 jidanni7 kernel: Modules linked in: nft_r... So please make clearer messages.
"Directories in Linux are accessible even if you don't have permissions to open their parent directory."
http://stackoverflow.com/questions/4864875/folder-for-temporary-files-creation-in-android-why-does-data-local-tmp-doesnt says "Directories in Linux are accessible even if you don't have permissions to open their parent directory." Could someone with enough Stackoverflow reputation points to enable commenting on Stackoverflow sites please post a qualification there. Thanks! -- 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/
Directories in Linux are accessible even if you don't have permissions to open their parent directory.
http://stackoverflow.com/questions/4864875/folder-for-temporary-files-creation-in-android-why-does-data-local-tmp-doesnt says Directories in Linux are accessible even if you don't have permissions to open their parent directory. Could someone with enough Stackoverflow reputation points to enable commenting on Stackoverflow sites please post a qualification there. Thanks! -- 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/
Idea: new parameter: save_boot_messages_to_a_file_on=/dev/sdb1
Problem: boot messages fly off the screen before the kernel panic is reached. Possible to write boot messages to a file on a USB stick? Gentlemen, we all know what a hassle it can be to get all those error messages that fly off your screen upon failed boots. One needs extra equipment etc. Well how about a new parameter that one could add there via typing "e" in grub, linux /boot/vmlinuz... root=... ro single panic=333 save_boot_messages_to_a_file_on=/dev/sdb1 Whereas normally the system would be just attempted to be booted, upon seeing the "save_boot_messages_to_a_file_on=" parameter, the kernel's first job would be to start writing copies of messages that it sends to the screen to some file (default BOOTMES.TXT) on /dev/sdb1 , then proceed to do the booting, making sure after writing its final stack trace to the screen to then close that file and sync it to the disk before giving up and starting the panic wait. -- 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/
Idea: new parameter: save_boot_messages_to_a_file_on=/dev/sdb1
Problem: boot messages fly off the screen before the kernel panic is reached. Possible to write boot messages to a file on a USB stick? Gentlemen, we all know what a hassle it can be to get all those error messages that fly off your screen upon failed boots. One needs extra equipment etc. Well how about a new parameter that one could add there via typing e in grub, linux /boot/vmlinuz... root=... ro single panic=333 save_boot_messages_to_a_file_on=/dev/sdb1 Whereas normally the system would be just attempted to be booted, upon seeing the save_boot_messages_to_a_file_on= parameter, the kernel's first job would be to start writing copies of messages that it sends to the screen to some file (default BOOTMES.TXT) on /dev/sdb1 , then proceed to do the booting, making sure after writing its final stack trace to the screen to then close that file and sync it to the disk before giving up and starting the panic wait. -- 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: disable "Call Trace:"
Here's another one I saw occupying the screen: [...] ---[ end trace ... ]--- [...] Fixing recursive fault but reboot is needed! Make sure that the user can also turn that one off and run it again to reveal the messages that were pushed off the screen above it. -- 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: disable Call Trace:
Here's another one I saw occupying the screen: [...] ---[ end trace ... ]--- [...] Fixing recursive fault but reboot is needed! Make sure that the user can also turn that one off and run it again to reveal the messages that were pushed off the screen above it. -- 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: disable "Call Trace:"
> "RD" == Randy Dunlap writes: RD> When would you want to disable it? at kernel boot time (as a boot option) RD> or sometime later? RD> But would you only want to disable Call Trace: on panics or any time that a RD> call trace might be printed? and would disabling call trace also disable RD> the raw stack dump and Code: output, or literally just the call trace? All I know is e.g., somehow something went wrong and the user finds himself unable to boot and unable to read the reason, as Linux is famous for not having a way to scroll messages that have flown off the screen and boot_delay= doesn't work good and he doesn't own another terminal he can plug into a port or even have a port etc. etc. etc. And he is sitting there and there is the reason, the main body of which has just flown off the screen. All pushed off due to this (useless to him) "Call Trace:" and some other hex stuff lying above "Call Trace". So if only he could please be able to, there hitting "e" in Grub, be able to add so "call_trace=no_thanks" "other_hex_stuff=no_thanks" to that linux command line, so then on the next run there will be something more left upon the screen! Thank you! -- 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: disable Call Trace:
RD == Randy Dunlap rdun...@infradead.org writes: RD When would you want to disable it? at kernel boot time (as a boot option) RD or sometime later? RD But would you only want to disable Call Trace: on panics or any time that a RD call trace might be printed? and would disabling call trace also disable RD the raw stack dump and Code: output, or literally just the call trace? All I know is e.g., somehow something went wrong and the user finds himself unable to boot and unable to read the reason, as Linux is famous for not having a way to scroll messages that have flown off the screen and boot_delay= doesn't work good and he doesn't own another terminal he can plug into a port or even have a port etc. etc. etc. And he is sitting there and there is the reason, the main body of which has just flown off the screen. All pushed off due to this (useless to him) Call Trace: and some other hex stuff lying above Call Trace. So if only he could please be able to, there hitting e in Grub, be able to add so call_trace=no_thanks other_hex_stuff=no_thanks to that linux command line, so then on the next run there will be something more left upon the screen! Thank you! -- 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/
disable "Call Trace:"
Idea: if the user could disable the "Call Trace:" seen upon "Kernel panic - not syncing: attempted to kill init!" he would then be able to see more lines above without having it shoved off the screen with the useless (to him) call trace. e.g., using panic=222 call_trace=disabled would give him enough time and room to read more of what happened from the screen. -- 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/
disable Call Trace:
Idea: if the user could disable the Call Trace: seen upon Kernel panic - not syncing: attempted to kill init! he would then be able to see more lines above without having it shoved off the screen with the useless (to him) call trace. e.g., using panic=222 call_trace=disabled would give him enough time and room to read more of what happened from the screen. -- 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/
