Two glitches in arch-chroot: "kernel paging" and "squashfs_read_data"

anne · 2014-01-06 01:39:36

I've just installed ArchLinux for the first time, and while I now have a bootable system, I encountered a couple of glitches which I thought I should report, since they're probably due to kernel bugs. Both occurred while I was running the installation system from a USB key, and while I was in arch-chroot.

The first glitch occurred when I did "gummiboot install"; the process hung hard, and even "kill -9" wouldn't touch it, despite the fact that "ps" showed it in state "R", not "D". Interestingly, it looked as though gummiboot had done its thing (based on the contents of the disk as viewed from a session in another, non-chrooted, xterm). I dumped out the journal file at that point. The relevant part is:

Jan 05 03:53:13 arch kernel: BUG: unable to handle kernel paging request at 00000000ff830000
Jan 05 03:53:13 arch kernel: IP: [<ffff88008e9dc1a8>] 0xffff88008e9dc1a7
Jan 05 03:53:13 arch kernel: PGD 217a6d067 PUD 0 
Jan 05 03:53:13 arch kernel: Oops: 0000 [#1] PREEMPT SMP 
Jan 05 03:53:13 arch kernel: Modules linked in: nls_cp437 vfat fat dm_crypt raid1 md_mod xfs nilfs2 jfs btrfs raid6_pq libcrc32c xor kvm_amd kvm crct10dif_pclmul crct10dif_common ppdev crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper snd_hda_codec_realtek ablk_helper cryptd snd_hda_codec_hdmi snd_hda_intel psmouse snd_hda_codec microcode snd_hwdep serio_raw snd_pcm pcspkr k10temp parport_pc snd_page_alloc parport snd_timer shpchp snd evdev acpi_cpufreq soundcore i2c_piix4 processor nfs lockd sunrpc fscache ext4 crc16 mbcache jbd2 dm_snapshot dm_mod squashfs loop isofs hid_generic usb_storage usbhid hid sr_mod cdrom sd_mod crc32c_intel ehci_pci ohci_pci radeon ohci_hcd xhci_hcd ehci_hcd ahci libahci i2c_algo_bit drm_kms_helper libata ttm scsi_mod usbcore usb_common drm r8169 mii i2c_core
Jan 05 03:53:13 arch kernel:  button
Jan 05 03:53:13 arch kernel: CPU: 2 PID: 10282 Comm: gummiboot Not tainted 3.12.3-1-ARCH #1
Jan 05 03:53:13 arch kernel: Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A85XM-D3H, BIOS F3 04/08/2013
Jan 05 03:53:13 arch kernel: task: ffff88020de170f0 ti: ffff8802108d2000 task.ti: ffff8802108d2000
Jan 05 03:53:13 arch kernel: RIP: 0010:[<ffff88008e9dc1a8>]  [<ffff88008e9dc1a8>] 0xffff88008e9dc1a7
Jan 05 03:53:13 arch kernel: RSP: 0018:ffff8802108d3970  EFLAGS: 00010006
Jan 05 03:53:13 arch kernel: RAX: 00000000ff830000 RBX: 0000000000000000 RCX: 0000000000000000
Jan 05 03:53:13 arch kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000010
Jan 05 03:53:13 arch kernel: RBP: ffffc900008b0000 R08: ffff88008e9df110 R09: 0000000000000008
Jan 05 03:53:13 arch kernel: R10: 0000000000020000 R11: 00000000000100ff R12: 0000000000000001
Jan 05 03:53:13 arch kernel: R13: 0000000000000000 R14: ffffc900008d0000 R15: ffffc900008d0000
Jan 05 03:53:13 arch kernel: FS:  00007f8ca79de780(0000) GS:ffff88023ed00000(0000) knlGS:0000000000000000
Jan 05 03:53:13 arch kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 05 03:53:13 arch kernel: CR2: 00000000ff830000 CR3: 000000020dd43000 CR4: 00000000000407e0
Jan 05 03:53:13 arch kernel: Stack:
Jan 05 03:53:13 arch kernel:  ffff8802108d3ae0 ffff88008e9d5170 ffff88008e9dfef8 ffff88008e9d44be
Jan 05 03:53:13 arch kernel:  0000000000000000 ffffc900008b0000 ffffc900008b0000 ffff88008e9d9c0c
Jan 05 03:53:13 arch kernel:  ffffc900008b0000 00000000ff830000 0000000000000000 0000000000000000
Jan 05 03:53:13 arch kernel: Call Trace:
Jan 05 03:53:13 arch kernel:  [<ffffffff811872de>] ? new_slab+0x21e/0x310
Jan 05 03:53:13 arch kernel:  [<ffffffff811b0a36>] ? link_path_walk+0x826/0x930
Jan 05 03:53:13 arch kernel:  [<ffffffff8105d9db>] ? efi_call5+0x4b/0x80
Jan 05 03:53:13 arch kernel:  [<ffffffff8105d111>] ? virt_efi_set_variable+0x31/0x40
Jan 05 03:53:13 arch kernel:  [<ffffffff8105d28d>] ? efi_query_variable_store+0x12d/0x1f0
Jan 05 03:53:13 arch kernel:  [<ffffffff813d0bc1>] ? efivar_entry_set_get_size+0x91/0x1a0
Jan 05 03:53:13 arch kernel:  [<ffffffff8122b067>] ? efivarfs_file_write+0xd7/0x190
Jan 05 03:53:13 arch kernel:  [<ffffffff811a484d>] ? vfs_write+0xbd/0x1e0
Jan 05 03:53:13 arch kernel:  [<ffffffff811b00f9>] ? putname+0x29/0x40
Jan 05 03:53:13 arch kernel:  [<ffffffff811a52a9>] ? SyS_write+0x49/0xa0
Jan 05 03:53:13 arch kernel:  [<ffffffff814fcf6d>] ? system_call_fastpath+0x1a/0x1f
Jan 05 03:53:13 arch kernel: Code: 00 80 ff 48 2b 05 c9 29 00 00 48 03 c8 4c 8b 05 27 39 00 00 8b c1 41 8b cd 48 89 44 24 48 45 39 68 54 76 1d 8b c1 48 03 44 24 48 <8a> 00 4c 8b 05 07 39 00 00 3c ff 75 09 41 03 cc 41 3b 48 54 72
Jan 05 03:53:13 arch kernel: RIP  [<ffff88008e9dc1a8>] 0xffff88008e9dc1a7
Jan 05 03:53:13 arch kernel:  RSP <ffff8802108d3970>
Jan 05 03:53:13 arch kernel: CR2: 00000000ff830000
Jan 05 03:53:13 arch kernel: ---[ end trace c9b95a95977a3db7 ]---
Jan 05 03:53:13 arch kernel: note: gummiboot[10282] exited with preempt_count 1
Jan 05 03:53:13 arch kernel: BUG: scheduling while atomic: gummiboot/10282/0x10000002
Jan 05 03:53:13 arch kernel: Modules linked in: nls_cp437 vfat fat dm_crypt raid1 md_mod xfs nilfs2 jfs btrfs raid6_pq libcrc32c xor kvm_amd kvm crct10dif_pclmul crct10dif_common ppdev crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper snd_hda_codec_realtek ablk_helper cryptd snd_hda_codec_hdmi snd_hda_intel psmouse snd_hda_codec microcode snd_hwdep serio_raw snd_pcm pcspkr k10temp parport_pc snd_page_alloc parport snd_timer shpchp snd evdev acpi_cpufreq soundcore i2c_piix4 processor nfs lockd sunrpc fscache ext4 crc16 mbcache jbd2 dm_snapshot dm_mod squashfs loop isofs hid_generic usb_storage usbhid hid sr_mod cdrom sd_mod crc32c_intel ehci_pci ohci_pci radeon ohci_hcd xhci_hcd ehci_hcd ahci libahci i2c_algo_bit drm_kms_helper libata ttm scsi_mod usbcore usb_common drm r8169 mii i2c_core
Jan 05 03:53:13 arch kernel:  button
Jan 05 03:53:13 arch kernel: CPU: 2 PID: 10282 Comm: gummiboot Tainted: G      D      3.12.3-1-ARCH #1
Jan 05 03:53:13 arch kernel: Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A85XM-D3H, BIOS F3 04/08/2013
Jan 05 03:53:13 arch kernel:  ffff88023ed144c0 ffff8802108d3350 ffffffff814ee3db ffff8802108d2000
Jan 05 03:53:13 arch kernel:  ffff8802108d3360 ffffffff814eb986 ffff8802108d3468 ffffffff814f39bf
Jan 05 03:53:13 arch kernel:  00000000000144c0 ffff8802108d3fd8 ffff8802108d3fd8 00000000000144c0
Jan 05 03:53:13 arch kernel: Call Trace:
Jan 05 03:53:13 arch kernel:  [<ffffffff814ee3db>] dump_stack+0x54/0x8d
Jan 05 03:53:13 arch kernel:  [<ffffffff814eb986>] __schedule_bug+0x4d/0x5b
Jan 05 03:53:13 arch kernel:  [<ffffffff814f39bf>] __schedule+0x93f/0x950
Jan 05 03:53:13 arch kernel:  [<ffffffff81298052>] ? put_dec+0x72/0x90
Jan 05 03:53:13 arch kernel:  [<ffffffff81298f93>] ? number.isra.1+0x323/0x360
Jan 05 03:53:13 arch kernel:  [<ffffffff8129ad44>] ? vsnprintf+0x214/0x680
Jan 05 03:53:13 arch kernel:  [<ffffffff81093306>] __cond_resched+0x26/0x30
Jan 05 03:53:13 arch kernel:  [<ffffffff814f3d9a>] _cond_resched+0x3a/0x50
Jan 05 03:53:13 arch kernel:  [<ffffffff8115db2d>] unmap_single_vma+0x5fd/0x8e0
Jan 05 03:53:13 arch kernel:  [<ffffffff8115ef69>] unmap_vmas+0x49/0x90
Jan 05 03:53:13 arch kernel:  [<ffffffff811682cc>] exit_mmap+0x9c/0x170
Jan 05 03:53:13 arch kernel:  [<ffffffff8105fc39>] mmput+0x59/0x110
Jan 05 03:53:13 arch kernel:  [<ffffffff8106502f>] do_exit+0x27f/0xab0
Jan 05 03:53:13 arch kernel:  [<ffffffff810b5d41>] ? kmsg_dump+0xc1/0xd0
Jan 05 03:53:13 arch kernel:  [<ffffffff814f67d1>] oops_end+0xa1/0xe0
Jan 05 03:53:13 arch kernel:  [<ffffffff814eb0dd>] no_context+0x281/0x28f
Jan 05 03:53:13 arch kernel:  [<ffffffff814eb171>] __bad_area_nosemaphore+0x86/0x1dc
Jan 05 03:53:13 arch kernel:  [<ffffffff814eb2da>] bad_area_nosemaphore+0x13/0x15
Jan 05 03:53:13 arch kernel:  [<ffffffff814f8e7e>] __do_page_fault+0x40e/0x5f0
Jan 05 03:53:13 arch kernel:  [<ffffffff8113ea68>] ? __alloc_pages_nodemask+0x158/0xaf0
Jan 05 03:53:13 arch kernel:  [<ffffffff8117eaa9>] ? alloc_pages_current+0xa9/0x160
Jan 05 03:53:13 arch kernel:  [<ffffffff811870b2>] ? setup_object.isra.45+0x52/0x60
Jan 05 03:53:13 arch kernel:  [<ffffffff811d6702>] ? __find_get_block+0xc2/0x290
Jan 05 03:53:13 arch kernel:  [<ffffffff811d6702>] ? __find_get_block+0xc2/0x290
Jan 05 03:53:13 arch kernel:  [<ffffffff814f906e>] do_page_fault+0xe/0x10
Jan 05 03:53:13 arch kernel:  [<ffffffff814f5c88>] page_fault+0x28/0x30
Jan 05 03:53:13 arch kernel:  [<ffffffff811872de>] ? new_slab+0x21e/0x310
Jan 05 03:53:13 arch kernel:  [<ffffffff811b0a36>] ? link_path_walk+0x826/0x930
Jan 05 03:53:13 arch kernel:  [<ffffffff8105d9db>] ? efi_call5+0x4b/0x80
Jan 05 03:53:13 arch kernel:  [<ffffffff8105d111>] ? virt_efi_set_variable+0x31/0x40
Jan 05 03:53:13 arch kernel:  [<ffffffff8105d28d>] ? efi_query_variable_store+0x12d/0x1f0
Jan 05 03:53:13 arch kernel:  [<ffffffff813d0bc1>] ? efivar_entry_set_get_size+0x91/0x1a0
Jan 05 03:53:13 arch kernel:  [<ffffffff8122b067>] ? efivarfs_file_write+0xd7/0x190
Jan 05 03:53:13 arch kernel:  [<ffffffff811a484d>] ? vfs_write+0xbd/0x1e0
Jan 05 03:53:13 arch kernel:  [<ffffffff811b00f9>] ? putname+0x29/0x40
Jan 05 03:53:13 arch kernel:  [<ffffffff811a52a9>] ? SyS_write+0x49/0xa0
Jan 05 03:53:13 arch kernel:  [<ffffffff814fcf6d>] ? system_call_fastpath+0x1a/0x1f
Jan 05 03:55:25 arch kernel: ------------[ cut here ]------------
Jan 05 03:55:25 arch kernel: WARNING: CPU: 3 PID: 10287 at kernel/watchdog.c:245 watchdog_overflow_callback+0x9c/0xd0()
Jan 05 03:55:25 arch kernel: Watchdog detected hard LOCKUP on cpu 3

There's more; I can supply the whole journal file if that will help.

Anyway, I reset the system, booted again from the installation media, remounted all my filesystems under /mnt, chrooted, re-did "gummiboot install" (it worked fine this time), and continued with my installation. I installed a fair bit of software while still in the arch-chroot, did some configuration, and finally exited the chroot with the intention of cleanly unmounting everything before rebooting my newly installed system from its own disks.

However, "umount -R /mnt" had problems. Again I dumped out the journal file; here's the relevant part:

Jan 05 07:21:05 arch kernel: SQUASHFS error: squashfs_read_data failed to read block 0xff87d00
Jan 05 07:21:05 arch kernel: SQUASHFS error: Unable to read data cache entry [ff87d00]
Jan 05 07:21:05 arch kernel: SQUASHFS error: Unable to read page, block ff87d00, size 9b1c

(The last two lines repeat several times until I just reboot the system.)

Anyway, the system did come up mostly fine; the remaining errors (with respect to activating swap and mounting an encrypted filesystem) are no doubt my own, and I'll read more about systemd before asking for help with those here.

So this post isn't a request for help, but rather a bug report. If there's any other information I can give that can help narrow down why the glitches might have happened, I'll be happy to supply it if I have it.

And since this is my first post here and my first experience with Arch Linux, allow me to say that the documentation has been excellent (and in fact, its high quality is what made me want to try this distro). The learning curve for me for some of the boot-time stuff is pretty steep (I'm used to Scientific Linux and NetBSD, lately), but I'm getting there! Thanks to all who've made this very interesting Linux distribution possible.

Anne.

anne · 2014-01-17 03:05:18

I wrote:

I've just installed ArchLinux for the first time, and while I now have a bootable system, I encountered a couple of glitches which I thought I should report, since they're probably due to kernel bugs.

Wow, 85 views and not a single response!

I think I may have a handle on what went wrong. While debugging errors that were reported while the system sets up swapping during boot, I realized that I had duplicate disk partition UUIDs. When I set up my disks, I partitioned the first, cloned the layout onto the second, and thought to randomize the disk UUID on the second disk, but, being new to GPT partition tables, I did not realize that each partition also has its own UUID, so I did not randomize those.

Fixing that mistake got rid of the swap set-up errors. And since, when I was first installing the system, I enabled the swap partitions as soon as I created them, this:

The first glitch occurred when I did "gummiboot install"; the process hung hard, and even "kill -9" wouldn't touch it, despite the fact that "ps" showed it in state "R", not "D".
Jan 05 03:53:13 arch kernel: BUG: unable to handle kernel paging request at 00000000ff830000

.. was probably swapping tripping all over itself because of two swap partitions with duplicate UUIDs. And this:

However, "umount -R /mnt" had problems.

Jan 05 07:21:05 arch kernel: SQUASHFS error: squashfs_read_data failed to read block 0xff87d00

... was probably due to another pair of partitions being "duplicated": the pair that make up my "big" logical volume, on which reside /, /var, and two data partitions.

So I'm not 100% ready to mark this as solved, but I have a pretty strong suspicion that the UUIDs caused the glitches.

Anne.

frank604 · 2014-01-17 08:31:32

anne wrote:

I've just installed ArchLinux for the first time, and while I now have a bootable system.

HELLO! Allow me to be one of the first to welcome you.

annie wrote:

So this post isn't a request for help, but rather a bug report.

Forum threads are not considered a bug report. If you believe it is upstream kernel, try bugzilla.kernel.org or else click on "Bugs" on the top right of page.

anne wrote:

And since this is my first post here and my first experience with Arch Linux, allow me to say that the documentation has been excellent (and in fact, its high quality is what made me want to try this distro). The learning curve for me for some of the boot-time stuff is pretty steep (I'm used to Scientific Linux and NetBSD, lately), but I'm getting there! Thanks to all who've made this very interesting Linux distribution possible.

That is a very big plus for me too. I feel as though I am connected to a large hive mind if you get my drift.

anne wrote:

Wow, 85 views and not a single response!

Sorry! I do not know what to suggest for this one. Good luck!

ewaller · 2014-01-17 18:24:45

frank604 wrote:

anne wrote:
Wow, 85 views and not a single response!
Sorry! I do not know what to suggest for this one. Good luck!

What can I say, these are very active forums and, clearly, the tread was seen by many. A lack of response can only mean that no one had anything to say. I have seen this sort of thing throughout my Linux experience. They are generally harmless, and are usually linked to unexpected hardware behavior rather than a problem with the kernel. Running Linux on random hardware makes us test pilots. Sometimes, you may be the first person to try a particular combination. We have no means of replicating your exact setup.

Arch Linux

#1 2014-01-06 01:39:36

Two glitches in arch-chroot: "kernel paging" and "squashfs_read_data"

#2 2014-01-17 03:05:18

Re: Two glitches in arch-chroot: "kernel paging" and "squashfs_read_data"

#3 2014-01-17 08:31:32

Re: Two glitches in arch-chroot: "kernel paging" and "squashfs_read_data"

#4 2014-01-17 18:24:45

Re: Two glitches in arch-chroot: "kernel paging" and "squashfs_read_data"

Board footer