Mount error on 32 bits, ok on 64 bits
Hi list, I have an Alix motherboard with a SD card using btrfs running fine since 2010. Today, I wanted to upgrade to kernel 4.13.4 from 4.9.52 (i586). As always, I cross-compiled from my main system, installed on Alix, but boot failed while trying to mount root: "BTRFS critical (device sda1): unable to find logical 1740640256 length 4096". Rebooting to 4.9.52 on the Alix works just fine. Btrfs scrub returns no error. Then I took off the SD card, and plugged it in my Intel desktop (running with kernel 4.13.3-x86_64), and ran a check: no errors were reported. I was also able to mount the file-system on that other system without trouble. I mounted with clear_cache, just in case, but it still it would not mount on the Alix system with kernel 4.13. One obvious different the 2 systems is 32 / 64 bits. Is this a known problem? How can I help to fix it? My Alix kernel config is attached Check and mount on the Intel system: [jdg@tiare linux]$ uname -a Linux tiare.sysnux.pf 4.13.3-snx #2 SMP Wed Sep 20 09:09:58 -10 2017 x86_64 x86_64 x86_64 GNU/Linux [jdg@tiare ~]$ sudo btrfs check /dev/sdd1 Checking filesystem on /dev/sdd1 UUID: 2e9cb3a5-f719-4c0a-a1f6-eef1dd9f84a8 checking extents checking free space cache checking fs roots checking csums checking root refs found 598966272 bytes used, no error found total csum bytes: 545176 total tree bytes: 40312832 total fs tree bytes: 36491264 total extent tree bytes: 2760704 btree space waste bytes: 10016852 file data blocks allocated: 558653440 referenced 987086848 BTRFS: device fsid 2e9cb3a5-f719-4c0a-a1f6-eef1dd9f84a8 devid 1 transid 1982285 /dev/sdd1 BTRFS info (device sdd1): force clearing of disk cache BTRFS info (device sdd1): disk space caching is enabled BTRFS info (device sdd1): has skinny extents BTRFS info (device sdd1): bdev /dev/sdd1 errs: wr 0, rd 0, flush 0, corrupt 4, gen 0 BTRFS info (device sdd1): checking UUID tree Info from the running Alix system: jdg@gw:~$ uname -a Linux gw.sysnux.pf 4.9.52-sysnux-ix100 #1 Thu Sep 28 12:49:53 -10 2017 i586 GNU/Linux jdg@gw:~$ sudo btrfs scrub start -B / scrub done for 2e9cb3a5-f719-4c0a-a1f6-eef1dd9f84a8 scrub started at Thu Sep 28 14:48:17 2017 and finished after 00:00:30 total bytes scrubbed: 570.76MiB with 0 errors jdg@gw:~$ sudo btrfs dev stats / [/dev/sda1].write_io_errs0 [/dev/sda1].read_io_errs 0 [/dev/sda1].flush_io_errs0 [/dev/sda1].corruption_errs 4 [/dev/sda1].generation_errs 0 Boot failure on Alix with 4.13.4: Btrfs loaded, crc32c=crc32c-generic ata1.00: CFA: SanDisk SDCFH-008G, HDX 6.03, max UDMA/66 ata1.00: 15625216 sectors, multi 0: LBA48 ata1.00: limited to UDMA/33 due to 40-wire cable ata1.00: configured for UDMA/33 scsi 0:0:0:0: Direct-Access ATA SanDisk SDCFH-00 6.03 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 15625216 512-byte logical blocks: (8.00 GB/7.45 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk BTRFS: device fsid 2e9cb3a5-f719-4c0a-a1f6-eef1dd9f84a8 devid 1 transid 1982236 /dev/root BTRFS info (device sda1): disk space caching is enabled BTRFS info (device sda1): has skinny extents BTRFS critical (device sda1): unable to find logical 1740640256 length 4096 BTRFS error (device sda1): failed to read chunk root BTRFS error (device sda1): open_ctree failed List of all partitions: 0800 7812608 sda driver: sd 0801 2097152 sda1 -01 No filesystem could mount root, tried: btrfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1) Thanks, -- Jean-Denis Girard SysNux Systèmes Linux en Polynésie française https://www.sysnux.pf/ Tél: +689 40.50.10.40 / GSM: +689 87.797.527 # # Automatically generated file; DO NOT EDIT. # Linux/i386 4.13.4 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_BITS_MAX=16 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=2 CONFIG_D
Re: Mount error on 32 bits, ok on 64 bits
Le 28/09/2017 à 15:29, Jean-Denis Girard a écrit : > Hi list, > > I have an Alix motherboard with a SD card using btrfs running fine since > 2010. Today, I wanted to upgrade to kernel 4.13.4 from 4.9.52 (i586). As > always, I cross-compiled from my main system, installed on Alix, but > boot failed while trying to mount root: "BTRFS critical (device sda1): > unable to find logical 1740640256 length 4096". > > Rebooting to 4.9.52 on the Alix works just fine. Btrfs scrub returns no > error. FWIW, kernels up to 4.12.14 are ok, and 4.13-rc1 has the same probem. Which patches should I try to reverse first? Thanks, -- Jean-Denis Girard SysNux Systèmes Linux en Polynésie française https://www.sysnux.pf/ Tél: +689 40.50.10.40 / GSM: +689 87.797.527 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mount error on 32 bits, ok on 64 bits
Le 28/09/2017 à 19:26, Jean-Denis Girard a écrit : > Le 28/09/2017 à 15:29, Jean-Denis Girard a écrit : > FWIW, kernels up to 4.12.14 are ok, and 4.13-rc1 has the same probem. > Which patches should I try to reverse first? The problem seems to come from commit c821e7f3 "pass bytes to btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/): the system is now running fine on 4.13.4 with only that patch reverted. Thanks, -- Jean-Denis Girard SysNux Systèmes Linux en Polynésie française https://www.sysnux.pf/ Tél: +689 40.50.10.40 / GSM: +689 87.797.527 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mount error on 32 bits, ok on 64 bits
Le 30/09/2017 à 17:29, Jean-Denis Girard a écrit : > Le 28/09/2017 à 19:26, Jean-Denis Girard a écrit : > The problem seems to come from commit c821e7f3 "pass bytes to > btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/): the > system is now running fine on 4.13.4 with only that patch reverted. Same situation with 4.14-rc3: my system cannot mount root file-system. If I revert the patch, the system boots normally. This is 100% reproducible. How can I help resolve that issue? Thanks, -- Jean-Denis Girard SysNux Systèmes Linux en Polynésie française https://www.sysnux.pf/ Tél: +689 40.50.10.40 / GSM: +689 87.797.527 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mount error on 32 bits, ok on 64 bits
On 10/02/2017 07:59 PM, Jean-Denis Girard wrote: > Le 30/09/2017 à 17:29, Jean-Denis Girard a écrit : >> Le 28/09/2017 à 19:26, Jean-Denis Girard a écrit : >> The problem seems to come from commit c821e7f3 "pass bytes to >> btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/): the >> system is now running fine on 4.13.4 with only that patch reverted. > > Same situation with 4.14-rc3: my system cannot mount root file-system. > If I revert the patch, the system boots normally. This is 100% > reproducible. How can I help resolve that issue? Looking at the patch, it seems suspect this chunk: @@ -2798,7 +2798,7 @@ static int submit_extent_page(int op, int op_flags, struct extent_io_tree *tree, } } - bio = btrfs_bio_alloc(bdev, sector); + bio = btrfs_bio_alloc(bdev, sector << 9); bio_add_page(bio, page, page_size, offset); bio->bi_end_io = end_io_func; bio->bi_private = tree; Now sector, is defined as sector_t [1] which in turn it might be defined as unsigned long [2] which on 32bit is 32 bit if CONFIG_LBDAF is _not_ defined (CONFIG_LBDAF == Support for large (2TB+) block devices and files) The point is that sector << 9 may overflow if the disk is bigger than 4GB (and in your case it seems to be 8 GB). If I am correct, could you please so kindly to - repllay the patch - AND try to replace bio = btrfs_bio_alloc(bdev, sector << 9); with bio = btrfs_bio_alloc(bdev, (u64)sector << 9); [1] http://elixir.free-electrons.com/linux/latest/source/fs/btrfs/extent_io.c#L2762 [2] http://elixir.free-electrons.com/linux/latest/source/include/linux/types.h#L133 > > > Thanks, > BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mount error on 32 bits, ok on 64 bits
On 10/02/2017 11:46 PM, Goffredo Baroncelli wrote: > which on 32bit is 32 bit if CONFIG_LBDAF is _not_ defined (CONFIG_LBDAF == > Support for large (2TB+) block devices and files) Only now I noticed that in the first email you attached the config; in fact in your config CONFIG_LBDAF is not set. BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mount error on 32 bits, ok on 64 bits
Le 02/10/2017 à 11:46, Goffredo Baroncelli a écrit : > On 10/02/2017 07:59 PM, Jean-Denis Girard wrote: >> Le 30/09/2017 à 17:29, Jean-Denis Girard a écrit : >>> Le 28/09/2017 à 19:26, Jean-Denis Girard a écrit : >>> The problem seems to come from commit c821e7f3 "pass bytes to >>> btrfs_bio_alloc" (https://patchwork.kernel.org/patch/9763081/): the >>> system is now running fine on 4.13.4 with only that patch reverted. >> >> Same situation with 4.14-rc3: my system cannot mount root file-system. >> If I revert the patch, the system boots normally. This is 100% >> reproducible. How can I help resolve that issue? > > > Looking at the patch, it seems suspect this chunk: > > @@ -2798,7 +2798,7 @@ static int submit_extent_page(int op, int op_flags, > struct extent_io_tree *tree, > } > } > > - bio = btrfs_bio_alloc(bdev, sector); > + bio = btrfs_bio_alloc(bdev, sector << 9); > bio_add_page(bio, page, page_size, offset); > bio->bi_end_io = end_io_func; > bio->bi_private = tree; > > Now sector, is defined as > > sector_t [1] > > which in turn it might be defined as > > unsigned long [2] > > which on 32bit is 32 bit if CONFIG_LBDAF is _not_ defined (CONFIG_LBDAF == > Support for large (2TB+) block devices and files) > > The point is that > > sector << 9 > > may overflow if the disk is bigger than 4GB (and in your case it seems to be > 8 GB). > > If I am correct, could you please so kindly to > > - repllay the patch > - AND try to replace > bio = btrfs_bio_alloc(bdev, sector << 9); > with > bio = btrfs_bio_alloc(bdev, (u64)sector << 9); Hi Goffredo, Thanks for your reply, analysis and correction: it does work, tested on 4.13-rc3, my system boots fine. Best regards, -- Jean-Denis Girard SysNux Systèmes Linux en Polynésie française https://www.sysnux.pf/ Tél: +689 40.50.10.40 / GSM: +689 87.797.527 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html