Date: Thu, 29 Aug 2013 10:47:55 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Jase Thew <jase@FreeBSD.org>, Toomas Aas <toomas.aas@raad.tartu.ee> Cc: freebsd-stable@FreeBSD.org Subject: Re: [HEADS UP] change in devfs path matching logic Message-ID: <521EFCAB.5030200@FreeBSD.org> In-Reply-To: <521E3394.5050000@FreeBSD.org> References: <51F28A33.7040209@FreeBSD.org> <52176C7B.4070701@FreeBSD.org> <20130824230324.12371xhs3clidbi8@webmail.raad.tartu.ee> <521E3394.5050000@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 28/08/2013 20:29 Jase Thew said the following: > On 24/08/2013 21:03, Toomas Aas wrote: >> Hello! >> >> On Fri, 23 Aug 2013 Andriy Gapon <avg@FreeBSD.org> wrote: >> >>> >>> This change is about to be MFC-ed. >>> >>> on 26/07/2013 17:39 Andriy Gapon said the following: >>>> >>>> I have just committed a significant change to devfs path matching logic >>>> http://svnweb.freebsd.org/changeset/base/253677 >> >> I just rebuilt my 8-STABLE i386 system to r254796 and now receive a >> kernel panic on boot. If I remove my /etc/devfs.rules file, the panic >> does not happen. Can anyone point out what is wrong with my devfs.rules >> what the new path matching logic doesn't like? >> >> $ cat /etc/devfs.rules.old >> [localrules=10] >> add path "da*" mode 0660 group operator >> add path "usb/1.2.0" mode 0660 group uucp >> add path "usb/4.3.0" mode 0660 group operator >> >> >> The panic, as transcribed from screen: >> >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0x0 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc06dde21 >> stack pointer = 0x28:0xe8690a48 >> frame pointer = 0x28:0xe8690a80 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, iopl = 0 >> current process = 577 (ln) >> trap number = 12 >> panic: page fault >> KDB: stack backtrace: >> #0 0xc0670ece at kdb_backtrace+0x50 >> #1 0xc06449fa at panic+0x132 >> #2 0xc07eb1d2 at trap_fatal+0x21e >> #3 0xc07eb4e0 at trap_pfault+0x1c2 >> #4 0xc07ec251 at trap+0x3c1 >> #5 0xc07d95fc at calltrap+0x6 >> #6 0xc05c7001 at devfs_rule_run+0x13d >> #7 0xc05c70c3 at devfs_ruleset_applyde+0x25 >> #8 0xc05c71b3 at devfs_rules_apply+0x73 >> #9 0xc05cad51 at devfs_symlink+0x124 >> #10 0xc080d084 at VOP_SYMLINK_APV+0x4a >> #11 0xc06d2985 at kern_symlinkat+0x38b >> #12 0xc06d29da at kern_symlink+0x2e >> #13 0xc06d2a05 at symlink+0x29 >> #14 0xc07eb7c7 at syscall+0x1a1 >> #15 0xc07d9661 at Xint0x80_syscall+0x21 >> >> >> Thanks in advance! > > > I'm getting a similar panic with r254986 on stable/8 when starting up jails : Thank you very much for the report. Somehow I missed Toomas'es report on the mailing list. It looks like I should have done more investigation on the state of devfs in stable/8 before MFC-ing the change. There are several earlier big commits that have not been MFC-ed. So, now I can either revert the MFC and be done with it. Or we can try to investigate the crash and see if it's easy to fix it. Do you guys have crashdumps from the panic? > # cat /var/crash/version.txt > FreeBSD 8.4-STABLE #1 r254986M: Wed Aug 28 16:26:23 BST 2013 > root@jailhost.localdomain:/usr/obj/usr/src/sys/JAILHOST > > # cat /etc/devfs.rules > [devfsrules_jailzfs=5] > add include $devfsrules_jail > add path 'zfs' unhide > > [devfsrules_jail_tinderbox=6] > add include $devfsrules_jail > add path 'zfs' unhide > add path 'mem' unhide > add path 'kmem' unhide > > # awk '/Fatal trap/,0' /var/crash/msgbuf.txt > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff806f8e46 > stack pointer = 0x28:0xffffff812375b670 > frame pointer = 0x28:0xffffff812375b6d0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1028 (ln) > trap number = 12 > panic: page fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff8020466a = db_trace_self_wrapper+0x2a > kdb_backtrace() at 0xffffffff80684df7 = kdb_backtrace+0x37 > panic() at 0xffffffff806510ce = panic+0x1ce > trap_fatal() at 0xffffffff809e8eb0 = trap_fatal+0x290 > trap_pfault() at 0xffffffff809e923e = trap_pfault+0x23e > trap() at 0xffffffff809e970e = trap+0x3ce > calltrap() at 0xffffffff809cf894 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff806f8e46, rsp = 0xffffff812375b670, rbp = > 0xffffff812375b6d0 --- > fnmatch() at 0xffffffff806f8e46 = fnmatch+0x66 > devfs_rule_run() at 0xffffffff805d255b = devfs_rule_run+0x17b > devfs_ruleset_applyde() at 0xffffffff805d2621 = devfs_ruleset_applyde+0x31 > devfs_rules_apply() at 0xffffffff805d274a = devfs_rules_apply+0x6a > devfs_symlink() at 0xffffffff805d624e = devfs_symlink+0x13e > VOP_SYMLINK_APV() at 0xffffffff80a78f58 = VOP_SYMLINK_APV+0x68 > kern_symlinkat() at 0xffffffff806edc9e = kern_symlinkat+0x38e > amd64_syscall() at 0xffffffff809e8484 = amd64_syscall+0x1f4 > Xfast_syscall() at 0xffffffff809cfb8c = Xfast_syscall+0xfc > --- syscall (57, FreeBSD ELF64, symlink), rip = 0x8006a08bc, rsp = > 0x7fffffffd838, rbp = 0x7fffffffed27 --- > Uptime: 2m39s -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521EFCAB.5030200>