Re: Kernel 3.10.x will be new longterm in Th
On Mon, 18 Nov 2013 22:31:28 +0100 Jan Rękorajski bagg...@pld-linux.org wrote: Could all owners of the intel graphics cards test 3.10.19-4 kernel package available in th-test? I applied a patch that attempts to fix/workaround black screen problems. Works for me: 00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02) Though I have never seen a 'black screen' problem on this machine. I had many other i915 driver problems here, though. There is other thing, though. During the file-system check on boot (I had quite an uptime here before rebooting) I got: [ 360.983319] INFO: task kworker/u16:4:361 blocked for more than 120 seconds. [ 360.986155] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 360.988993] kworker/u16:4 D f6969f80 0 361 2 0x [ 360.991846] Workqueue: writeback bdi_writeback_workfn (flush-254:9) [ 360.994675] f64edc10 0046 f6969f80 f64edc20 c16fd1c0 35672000 0020 [ 360.997532] c16fd1c0 f6d6f1c0 f69f4b70 f64edbe0 c1229e93 f64edc10 c158cc22 c158cc22 [ 361.000385] 0086 f3c98001 f3c98000 f3c98000 c1628120 f64edbf8 c1051c8e f3c98000 [ 361.003235] Call Trace: [ 361.006039] [c1229e93] ? format_decode+0x323/0x390 [ 361.008862] [c1051c8e] ? internal_add_timer+0xe/0x30 [ 361.011737] [c109125f] ? ktime_get_ts+0x3f/0x110 [ 361.014519] [c145a31e] schedule+0x1e/0x50 [ 361.014521] [c145a533] io_schedule+0x73/0xb0 [ 361.014524] [c10f65d8] sleep_on_page+0x8/0x10 [ 361.014526] [c1458fe1] __wait_on_bit_lock+0x41/0x90 [ 361.014528] [c10f6a02] ? find_get_pages_tag+0x92/0x100 [ 361.014529] [c10f65d0] ? filemap_fdatawait+0x60/0x60 [ 361.014531] [c10f6716] __lock_page+0x76/0x80 [ 361.014534] [c1063a00] ? autoremove_wake_function+0x40/0x40 [ 361.014554] [f845f6af] ext4_num_dirty_pages.isra.39+0x18f/0x1a0 [ext4] [ 361.014559] [c1100da2] ? pagevec_lookup_tag+0x22/0x30 [ 361.014570] [f8463ae0] ext4_da_writepages+0x4f0/0x560 [ext4] [ 361.014572] [c10fe890] ? mapping_tagged+0x10/0x10 [ 361.014574] [c10761c8] ? dequeue_task_fair+0x208/0x630 [ 361.014576] [c1078ad1] ? update_group_power+0x1f1/0x230 [ 361.014579] [c1222388] ? cpumask_next_and+0x28/0x40 [ 361.014581] [c1078c2e] ? find_busiest_group+0x11e/0x980 [ 361.014583] [c11002a5] do_writepages+0x15/0x40 [ 361.014586] [c1169c47] __writeback_single_inode+0x37/0x1d0 [ 361.014588] [c116aa2d] writeback_sb_inodes+0x15d/0x2d0 [ 361.014590] [c116ac14] __writeback_inodes_wb+0x74/0xb0 [ 361.014592] [c116ae3a] wb_writeback+0x1ea/0x260 [ 361.014595] [c115c239] ? get_nr_inodes+0x39/0x50 [ 361.014597] [c116b24a] wb_do_writeback+0x19a/0x1a0 [ 361.014598] [c122bbe6] ? vsnprintf+0x166/0x390 [ 361.014601] [c116b2ba] bdi_writeback_workfn+0x6a/0x170 [ 361.014603] [c105d9d5] process_one_work+0x105/0x330 [ 361.014605] [c105c780] ? start_worker+0x20/0x30 [ 361.014607] [c105e035] ? manage_workers.isra.26+0x1a5/0x250 [ 361.014609] [c105e1d9] worker_thread+0xf9/0x330 [ 361.014610] [c105e0e0] ? manage_workers.isra.26+0x250/0x250 [ 361.014613] [c1062f8f] kthread+0x8f/0xa0 [ 361.014615] [c1461ed7] ret_from_kernel_thread+0x1b/0x28 [ 361.014618] [c1062f00] ? kthread_create_on_node+0xc0/0xc0 [ 361.014623] INFO: task jbd2/dm-9-8:589 blocked for more than 120 seconds. [ 361.014624] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 361.014626] jbd2/dm-9-8 D f67b8034 0 589 2 0x [ 361.014630] ef11fe44 0046 f67b8034 f6d6f208 c16fd1c0 ad504ed0 0020 [ 361.014633] c16fd1c0 f6d7d1c0 f67b8000 c1071e35 f6d6f760 0001 f6d6f208 0039 [ 361.014636] e6bf19b3 000c b40e 0014 0246 [ 361.014636] Call Trace: [ 361.014640] [c1071e35] ? sched_clock_local+0x45/0x140 [ 361.014642] [c1063803] ? prepare_to_wait+0x43/0x70 [ 361.014643] [c145a31e] schedule+0x1e/0x50 [ 361.014650] [f83b5638] jbd2_journal_commit_transaction+0x1c8/0x1620 [jbd2] [ 361.014653] [c100debe] ? __switch_to+0xde/0x350 [ 361.014655] [c10639c0] ? wake_up_bit+0x20/0x20 [ 361.014656] [c1051fce] ? lock_timer_base.isra.36+0x1e/0x40 [ 361.014658] [c105208d] ? try_to_del_timer_sync+0x3d/0x50 [ 361.014664] [f83bae9b] kjournald2+0x9b/0x200 [jbd2] [ 361.014666] [c10639c0] ? wake_up_bit+0x20/0x20 [ 361.014671] [f83bae00] ? commit_timeout+0x10/0x10 [jbd2] [ 361.014673] [c1062f8f] kthread+0x8f/0xa0 [ 361.014676] [c1461ed7] ret_from_kernel_thread+0x1b/0x28 [ 361.014678] [c1062f00] ? kthread_create_on_node+0xc0/0xc0 [ 361.014679] INFO: task systemd-readahe:643 blocked for more than 120 seconds. [ 361.014680] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 361.014682] systemd-readahe D f65eecbc 0 643 1 0x [ 361.014685] f696592c 0082 f65eecbc f65eec28 c16fd1c0 3568 f674 [ 361.014688] c16fd1c0 f6d7d1c0 f67be610 c11ff979 f6965918 f6965908 c1201db3
Re: PLD New Rescue
On Tue, Nov 19, 2013 at 08:38:59AM +0100, Jacek Konieczny wrote: did you consider loading ISO9660 EFI driver to reuse main image contents? I don't have to. Nothing is duplicated on my image. I was thinking about adding the ISO9660 EFI but no I don't have a reason for that. Great, will hopefully borrow that :) Noted the difference in the number of partitions, my setup ends up with two GPT partitions within a hybrid ISO made this way: http://git.altlinux.org/people/mike/packages/?p=mkimage.git;a=blob;f=tools/mki-copy-efiboot;h=58f70a4746c72b9e2d3758a7d8d67d726e3a2fa4;hb=HEAD#l189 (.efiboot.img) http://git.altlinux.org/people/mike/packages/?p=mkimage.git;a=blob;f=tools/mki-pack-isoboot;h=85ca988c6aab94e3c44e64519baf2231e39d8d24;hb=HEAD#l77 (xorriso ... -isohybrid-mbr /usr/lib/syslinux/isohdpfx.bin -partition_offset 16 -eltorito-alt-boot -e EFI/.efiboot.img -no-emul-boot -isohybrid-gpt-basdat ...) and is booted with ELILO (that one is also convenient as a second shim for restrictedboot case as it only boots Linux kernels but doesn't just LoadImage() them so there's no need to sign those; shim-0.5 has broken this intentionally but I'm pretty happy with 0.4 one). Downloaded; boots fine in kvm but oopses on ASUS UX31A (i7-3517 Thanks for the information. I would be surprised if it boots everywhere. I'll recheck on my UEFI stand (AMD C60 mITX board). Purged older kernels during an accident leaving me with no kernels installed at all so can't share the config file, sorry -- 3.10 one is handy. Looks like some kernel/driver problem. I will release a new set of images, based on current PLD Th soon -- maybe that will work better. I am also considering using the kernel-rescuecd package instead of the full featured PLD kernel which is used now. Up to you, I chose to go with stock kernels (given these have aufs onboard). -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Kernel 3.10.x will be new longterm in Th
On Tue, 19 Nov 2013, Jacek Konieczny wrote: On Mon, 18 Nov 2013 22:31:28 +0100 Jan Rękorajski bagg...@pld-linux.org wrote: Could all owners of the intel graphics cards test 3.10.19-4 kernel package available in th-test? I applied a patch that attempts to fix/workaround black screen problems. Works for me: 00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02) Though I have never seen a 'black screen' problem on this machine. I had many other i915 driver problems here, though. Good to know, at least the patch doesn't seem break anything :) There is other thing, though. During the file-system check on boot (I had quite an uptime here before rebooting) I got: [ 360.983319] INFO: task kworker/u16:4:361 blocked for more than 120 seconds. [...] That looks scary, but the system started properly in the end. Looks like just threads waiting for device, if those task got unstuck eventually then I wouldn't worry. -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsatmimuw.edu.pl bagginsatpld-linux.org ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD New Rescue
On Tue, Nov 19, 2013 at 08:38:59AM +0100, Jacek Konieczny wrote: Thanks for the information. I would be surprised if it boots everywhere. It does boot on ASUS C60M1-I motherboard in UEFI mode just fine; BIOS mode would hang after setting up serial port grub message, pressing Ctrl doesn't affect this. -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD New Rescue
On Tue, 19 Nov 2013 19:33:26 +0200 Michael Shigorin m...@osdn.org.ua wrote: On Tue, Nov 19, 2013 at 08:38:59AM +0100, Jacek Konieczny wrote: Thanks for the information. I would be surprised if it boots everywhere. It does boot on ASUS C60M1-I motherboard in UEFI mode just fine; BIOS mode would hang after setting up serial port grub message, pressing Ctrl doesn't affect this. Weird. Its opposite what was happening on my wife's laptop — setting up serial port would hung in EFI mode, but does not affect BIOS boot. The 'press Ctrl' workaround is avaialble only in BIOS mode (GRUB serial console is completely disabled during EFI boot), as there is no way to do that on GRUB's EFI console. Maybe I have not tested this feature properly. Can you verify if commenting out serial port setup in grub.cfg fixes the problem? Greets, Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PLD New Rescue
On Tue, Nov 19, 2013 at 07:22:36PM +0100, Jacek Konieczny wrote: It does boot on ASUS C60M1-I motherboard in UEFI mode just fine; BIOS mode would hang after setting up serial port grub message, pressing Ctrl doesn't affect this. Weird. Its opposite what was happening on my wife's laptop -- setting up serial port would hung in EFI mode, but does not affect BIOS boot. IIRC there was a message that it's being skipped to avoid hang in UEFI mode; there's no physical connector on that motherboard and it might be that there's no logical port either. Can you verify if commenting out serial port setup in grub.cfg fixes the problem? Erm, modifying bootable ISOs was never that straightforward, I'll try to do that but can't promise. :) -- WBR, Michael Shigorin / http://altlinux.org -- http://opennet.ru / http://anna-news.info ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
