Date: Thu, 20 Dec 2018 13:04:49 -0500 From: Mark Johnston <markj@freebsd.org> To: Rebecca Cran <rebecca@bluestop.org> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@freebsd.org>, pho@freebsd.org, mckusick@freebsd.org Subject: Re: Panic in getblkx() booting from disc1.iso in Qemu VM Message-ID: <20181220180449.GD98252@raichu> In-Reply-To: <4628942.YNO7O01DYZ@photon.int.bluestop.org> References: <4628942.YNO7O01DYZ@photon.int.bluestop.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 20, 2018 at 10:33:20AM -0700, Rebecca Cran wrote: > I know booting from the cd/dvd iso worked fairly recently, but today booting a > new build of -CURRENT in a Qemu VM resulted in a panic: > > FreeBSD 13.0-CURRENT 19a6ceb89db(HEAD) GENERIC amd64 > FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM > 7.0.1) > WARNING: WITNESS option enabled, expect reduced performance. > VT(efifb): resolution 800x600 > CPU: QEMU Virtual CPU version 2.5+ (2994.86-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x663 Family=0x6 Model=0x6 Stepping=3 > Features=0x783fbfd<FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2> > Features2=0x80002001<SSE3,CX16,HV> > AMD Features=0x20100800<SYSCALL,NX,LM> > AMD Features2=0x5<LAHF,SVM> > SVM: NAsids=16 > Hypervisor: Origin = "TCGTCGTCGTCG" > real memory = 8589934592 (8192 MB) > avail memory = 8227643392 (7846 MB) > > ... > > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from cd9660:/dev/iso9660/13_0_CURRENT_AMD64_DVD [ro]... > panic: bsize == 0, check bo->bo_bsize > cpuid = 0 > time = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0041189270 > vpanic() at vpanic+0x1b4/frame 0xfffffe00411892d0 > panic() at panic+0x43/frame 0xfffffe0041189330 > getblkx() at getblkx+0x807/frame 0xfffffe00411893f0 > breadn_flags() at breadn_flags+0x3d/frame 0xfffffe0041189460 > cd9660_blkatoff() at cd9660_blkatoff+0x53/frame 0xfffffe00411894d0 > cd9660_vget_internal() at cd9660_vget_internal+0x26b/frame 0xfffffe0041189550 > vfs_domount() at vfs_domount+0x7d3/frame 0xfffffe0041189770 > vfs_donmount() at vfs_donmount+0x7b9/frame 0xfffffe0041189810 > kernel_mount() at kernel_mount+0x58/frame 0xfffffe0041189860 > parse_mount() at parse_mount+0x469/frame 0xfffffe00411899a0 > vfs_mountroot() at vfs_mountroot+0x67f/frame 0xfffffe0041189b10 > start_init() at start_init+0x28/frame 0xfffffe0041189bb0 > fork_exit() at fork_exit+0x84/frame 0xfffffe0041189bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0041189bf0 Peter reported the same problem with ext2. I believe this is a regression from r342135, which moved a VFS_ROOT call before VFS_STATFS. For most filesystems, VFS_STATFS is the place where mp->mnt_stat is initialized, so the problem arises because mnt_stat.f_iosize is still 0 when the root vnode is initialized. UFS initializes mnt_stat.f_iosize in its VFS_MOUNT implementation, so it is immune to this problem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181220180449.GD98252>