Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out()
On Wed, Aug 06, 2014 at 09:15:12PM +0300, Konstantin Belousov wrote: > On Wed, Aug 06, 2014 at 12:48:28PM -0500, Bryan Drewery wrote: > > On 8/5/2014 10:56 PM, Bryan Drewery wrote: > > > On 8/5/2014 10:19 PM, Konstantin Belousov wrote: > > >> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: > > >>> Has anyone else encountered this? Got it while running poudriere. > > >>> > > NULL mp in getnewvnode() > > [...] > > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247d8e540 > > vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247d8e590 > > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247d8e7c0 > > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > > 0xfe1247d8e840 > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > > 0xfe1247d8e900 > > sysctl_root_handler_locked() at > > sysctl_root_handler_locked+0x68/frame 0xfe1247d8e940 > > sysctl_root() at sysctl_root+0x18e/frame 0xfe1247d8e990 > > userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247d8ea30 > > sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247d8eae0 > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247d8ebf0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247d8ebf0 > > >>> > > >>> Unfortunately I have no dump as the kmem was too large compared to my > > >>> swap, and I didn't get to the console before some of the text was > > >>> overwritten. Perhaps it will hit it again soon after reboot and I'll get > > >>> a core. > > >> > > >> "NULL mp in getnewvnode()" is only the printf(), it is not a panic or > > >> KASSERT. The event does not stop the machine, nor it prints the > > >> backtrace. > > >> > > >> You mentioned that you was unable to dump, so did the system paniced ? > > >> Without full log of the panic messages and backtrace, it is impossible > > >> to start guessing what the problem is. > > >> > > >> That said, the printf seemingly outlived its usefulness. > > >> > > > > > > Got it. I've set debug.debugger_on_panic=1 to not auto reboot on panic > > > next time this happens. I had it at 0 which was causing the lack of > > > information in these. > > > > Here is the full trace: > > > > > > > NULL mp in getnewvnode() > > > VNASSERT failed > > > 0xf806071dc760: tag null, type VDIR > > > usecount 1, writecount 0, refcount 1 mountedhere 0 > > > flags () > > > lock type zfs: EXCL by thread 0xf8009a53f490 (pid 1028, tmux, tid > > > 100881) > > > vp=0xf806071dc760, lowervp=0xf8013157f588 > > > panic: Don't call insmntque(foo, NULL) > > > cpuid = 5 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > > 0xfe1247e76b50 > > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247e76c00 > > > vpanic() at vpanic+0x126/frame 0xfe1247e76c40 > > > kassert_panic() at kassert_panic+0x139/frame 0xfe1247e76cb0 > > > insmntque1() at insmntque1+0x230/frame 0xfe1247e76cf0 > > > null_nodeget() at null_nodeget+0x158/frame 0xfe1247e76d60 > > > null_lookup() at null_lookup+0xeb/frame 0xfe1247e76dd0 > > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfe1247e76e00 > > > lookup() at lookup+0x5ad/frame 0xfe1247e76e90 > > > namei() at namei+0x4e4/frame 0xfe1247e76f50 > > > vn_open_cred() at vn_open_cred+0x27a/frame 0xfe1247e770a0 > > > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfe1247e773e0 > > > null_vptocnp() at null_vptocnp+0x2b/frame 0xfe1247e77440 > > > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfe1247e77470 > > > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfe1247e774e0 > > > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247e77540 > > > vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247e77590 > > > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247e777c0 > > > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > > > 0xfe1247e77840 > > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > > > 0xfe1247e77900 > > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame > > > 0xfe1247e77940 > > > sysctl_root() at sysctl_root+0x18e/frame 0xfe1247e77990 > > > userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247e77a30 > > > sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247e77ae0 > > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247e77bf0 > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247e77bf0 > > > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x801041fca, rsp = > > > 0x7fffd878, rbp = 0x7fffd8b0 --- > > > KDB: enter: panic > > > [ thread pid 1028 tid 100881 ] > > > Stopped at kdb_enter+0x3e: movq$0,kdb_why > > > db> call doadump() > > > > > > Dump failed. Partition too small. > > > = 0 > > > > Try this. > > diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c > ind
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Wed, 6 Aug 2014 22:48+0200, Trond Endrestøl wrote: > On Wed, 6 Aug 2014 19:21+0200, Trond Endrestøl wrote: > > > On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > > > > > > > On Aug 5, 2014, at 2:29 PM, Michael Butler > > > wrote: > > > > > > > On 08/05/14 16:56, Michael Butler wrote: > > > >> On 08/05/14 16:02, John Baldwin wrote: > > > >> > > > >>> My guess is that the recent Xen changes tickled something. > > > >> > > > >> I can confirm this on a kernel which is otherwise up to date .. > > > >> > > > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > > > >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > > > >> > > > >> I backed out all of SVN r269507 through r269515. > > > >> > > > >> Now working .. > > > > > > > > [ .. snip .. ] > > > > > > > >> Now to see if it's related to the other machine's disk woes (it's a > > > >> single-core device), > > > > > > > > And it fixes the inability to probe disks on my single-core machine :-) > > > > > > It looks like the MADT code to probe the I/O APICs isn't working so > > > it's trying to fall back to using the ATPIC while using SMP (which > > > doesn't work). I know it's a pain on a laptop, but if it is at all > > > possible to capture either a verbose or non-verbose dmesg that would > > > really help narrow it down. > > > > > > Also, if anyone can try reverting just the MADT-related changes in > > > the recent Xen changes to see if you can narrow down which exact one > > > triggers the panic that would be really helpful. > > > > I noticed this panic on i386 head r269607 yesterday, running in VBox > > on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz > > (3175.67-MHz 686-class CPU). > > > > Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a > > verbose dmesg from i386 head r268838 from the same VM and a couple of > > screenshots of the crash while booting r269607 with the verbose flag > > on. > > > > I'm rewinding /usr/src to r269507, and I'll take it from there, one > > commit at the time. > > Reverting r269510 did the trick, i.e.: > > cd /usr/src && svn up && svn diff -r 269510:269509 | patch > > My i386 head VM is running smoothly with r269641M, with M meaning only > the above reversal. > > > I'll also try to investigate this panic using my amd64 head VM. > > Work in progress. amd64 is unaffected, as r269644 worked without any modifications. I'm guessing the changes to sys/x86/x86/local_apic.c and sys/x86/xen/xen_intr.c come as a pair. If not, then the changes done to sys/x86/x86/local_apic.c is the culprit somehow. Trond, going to bed. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/14 17:07, David Wolfskill wrote: > On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestøl wrote: >> ... Reverting r269510 did the trick, i.e.: >> >> cd /usr/src && svn up && svn diff -r 269510:269509 | patch >> >> My i386 head VM is running smoothly with r269641M, with M meaning >> only the above reversal. Solves the problem for both of my machines, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlPinEkACgkQQv9rrgRC1JLZfACgiiXUShFuZSSGcHdp256kdKM+ Du8An2St9nEIaTC6ViBNCrET+rXGD10I =vkkP -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Wed, Aug 06, 2014 at 10:48:32PM +0200, Trond Endrestøl wrote: > ... > Reverting r269510 did the trick, i.e.: > > cd /usr/src && svn up && svn diff -r 269510:269509 | patch > > My i386 head VM is running smoothly with r269641M, with M meaning only > the above reversal. > ... Works for me, as well -- thanks! FreeBSD 11.0-CURRENT #1333 r269622M/269622:1100028: Wed Aug 6 14:01:30 PDT 2014 (I'll be providing more details to royger@ et al. in a moment.) Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpNtzZXKfHZl.pgp Description: PGP signature
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Wed, 6 Aug 2014 19:21+0200, Trond Endrestøl wrote: > On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > > > > On Aug 5, 2014, at 2:29 PM, Michael Butler > > wrote: > > > > > On 08/05/14 16:56, Michael Butler wrote: > > >> On 08/05/14 16:02, John Baldwin wrote: > > >> > > >>> My guess is that the recent Xen changes tickled something. > > >> > > >> I can confirm this on a kernel which is otherwise up to date .. > > >> > > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > > >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > > >> > > >> I backed out all of SVN r269507 through r269515. > > >> > > >> Now working .. > > > > > > [ .. snip .. ] > > > > > >> Now to see if it's related to the other machine's disk woes (it's a > > >> single-core device), > > > > > > And it fixes the inability to probe disks on my single-core machine :-) > > > > It looks like the MADT code to probe the I/O APICs isn't working so > > it's trying to fall back to using the ATPIC while using SMP (which > > doesn't work). I know it's a pain on a laptop, but if it is at all > > possible to capture either a verbose or non-verbose dmesg that would > > really help narrow it down. > > > > Also, if anyone can try reverting just the MADT-related changes in > > the recent Xen changes to see if you can narrow down which exact one > > triggers the panic that would be really helpful. > > I noticed this panic on i386 head r269607 yesterday, running in VBox > on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz > (3175.67-MHz 686-class CPU). > > Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a > verbose dmesg from i386 head r268838 from the same VM and a couple of > screenshots of the crash while booting r269607 with the verbose flag > on. > > I'm rewinding /usr/src to r269507, and I'll take it from there, one > commit at the time. Reverting r269510 did the trick, i.e.: cd /usr/src && svn up && svn diff -r 269510:269509 | patch My i386 head VM is running smoothly with r269641M, with M meaning only the above reversal. > I'll also try to investigate this panic using my amd64 head VM. Work in progress. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out()
On Wed, Aug 06, 2014 at 12:48:28PM -0500, Bryan Drewery wrote: > On 8/5/2014 10:56 PM, Bryan Drewery wrote: > > On 8/5/2014 10:19 PM, Konstantin Belousov wrote: > >> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: > >>> Has anyone else encountered this? Got it while running poudriere. > >>> > NULL mp in getnewvnode() > [...] > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247d8e540 > vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247d8e590 > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247d8e7c0 > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > 0xfe1247d8e840 > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > 0xfe1247d8e900 > sysctl_root_handler_locked() at > sysctl_root_handler_locked+0x68/frame 0xfe1247d8e940 > sysctl_root() at sysctl_root+0x18e/frame 0xfe1247d8e990 > userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247d8ea30 > sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247d8eae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247d8ebf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247d8ebf0 > >>> > >>> Unfortunately I have no dump as the kmem was too large compared to my > >>> swap, and I didn't get to the console before some of the text was > >>> overwritten. Perhaps it will hit it again soon after reboot and I'll get > >>> a core. > >> > >> "NULL mp in getnewvnode()" is only the printf(), it is not a panic or > >> KASSERT. The event does not stop the machine, nor it prints the > >> backtrace. > >> > >> You mentioned that you was unable to dump, so did the system paniced ? > >> Without full log of the panic messages and backtrace, it is impossible > >> to start guessing what the problem is. > >> > >> That said, the printf seemingly outlived its usefulness. > >> > > > > Got it. I've set debug.debugger_on_panic=1 to not auto reboot on panic > > next time this happens. I had it at 0 which was causing the lack of > > information in these. > > Here is the full trace: > > > > NULL mp in getnewvnode() > > VNASSERT failed > > 0xf806071dc760: tag null, type VDIR > > usecount 1, writecount 0, refcount 1 mountedhere 0 > > flags () > > lock type zfs: EXCL by thread 0xf8009a53f490 (pid 1028, tmux, tid > > 100881) > > vp=0xf806071dc760, lowervp=0xf8013157f588 > > panic: Don't call insmntque(foo, NULL) > > cpuid = 5 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe1247e76b50 > > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247e76c00 > > vpanic() at vpanic+0x126/frame 0xfe1247e76c40 > > kassert_panic() at kassert_panic+0x139/frame 0xfe1247e76cb0 > > insmntque1() at insmntque1+0x230/frame 0xfe1247e76cf0 > > null_nodeget() at null_nodeget+0x158/frame 0xfe1247e76d60 > > null_lookup() at null_lookup+0xeb/frame 0xfe1247e76dd0 > > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfe1247e76e00 > > lookup() at lookup+0x5ad/frame 0xfe1247e76e90 > > namei() at namei+0x4e4/frame 0xfe1247e76f50 > > vn_open_cred() at vn_open_cred+0x27a/frame 0xfe1247e770a0 > > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfe1247e773e0 > > null_vptocnp() at null_vptocnp+0x2b/frame 0xfe1247e77440 > > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfe1247e77470 > > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfe1247e774e0 > > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247e77540 > > vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247e77590 > > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247e777c0 > > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > > 0xfe1247e77840 > > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > > 0xfe1247e77900 > > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame > > 0xfe1247e77940 > > sysctl_root() at sysctl_root+0x18e/frame 0xfe1247e77990 > > userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247e77a30 > > sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247e77ae0 > > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247e77bf0 > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247e77bf0 > > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x801041fca, rsp = > > 0x7fffd878, rbp = 0x7fffd8b0 --- > > KDB: enter: panic > > [ thread pid 1028 tid 100881 ] > > Stopped at kdb_enter+0x3e: movq$0,kdb_why > > db> call doadump() > > > > Dump failed. Partition too small. > > = 0 > Try this. diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c index 481644c..e803c24 100644 --- a/sys/fs/nullfs/null_vnops.c +++ b/sys/fs/nullfs/null_vnops.c @@ -361,9 +361,11 @@ null_lookup(struct vop_lookup_args *ap) struct vnode *dvp = ap->a_dvp; int flags = cnp->cn_flags; struct vnode *vp, *ldvp, *lvp; +
Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out()
On 8/5/2014 10:56 PM, Bryan Drewery wrote: > On 8/5/2014 10:19 PM, Konstantin Belousov wrote: >> On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: >>> Has anyone else encountered this? Got it while running poudriere. >>> NULL mp in getnewvnode() [...] vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247d8e540 vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247d8e590 export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247d8e7c0 kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfe1247d8e840 sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xfe1247d8e900 sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0xfe1247d8e940 sysctl_root() at sysctl_root+0x18e/frame 0xfe1247d8e990 userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247d8ea30 sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247d8eae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247d8ebf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247d8ebf0 >>> >>> Unfortunately I have no dump as the kmem was too large compared to my >>> swap, and I didn't get to the console before some of the text was >>> overwritten. Perhaps it will hit it again soon after reboot and I'll get >>> a core. >> >> "NULL mp in getnewvnode()" is only the printf(), it is not a panic or >> KASSERT. The event does not stop the machine, nor it prints the >> backtrace. >> >> You mentioned that you was unable to dump, so did the system paniced ? >> Without full log of the panic messages and backtrace, it is impossible >> to start guessing what the problem is. >> >> That said, the printf seemingly outlived its usefulness. >> > > Got it. I've set debug.debugger_on_panic=1 to not auto reboot on panic > next time this happens. I had it at 0 which was causing the lack of > information in these. Here is the full trace: > NULL mp in getnewvnode() > VNASSERT failed > 0xf806071dc760: tag null, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type zfs: EXCL by thread 0xf8009a53f490 (pid 1028, tmux, tid > 100881) > vp=0xf806071dc760, lowervp=0xf8013157f588 > panic: Don't call insmntque(foo, NULL) > cpuid = 5 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1247e76b50 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247e76c00 > vpanic() at vpanic+0x126/frame 0xfe1247e76c40 > kassert_panic() at kassert_panic+0x139/frame 0xfe1247e76cb0 > insmntque1() at insmntque1+0x230/frame 0xfe1247e76cf0 > null_nodeget() at null_nodeget+0x158/frame 0xfe1247e76d60 > null_lookup() at null_lookup+0xeb/frame 0xfe1247e76dd0 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfe1247e76e00 > lookup() at lookup+0x5ad/frame 0xfe1247e76e90 > namei() at namei+0x4e4/frame 0xfe1247e76f50 > vn_open_cred() at vn_open_cred+0x27a/frame 0xfe1247e770a0 > vop_stdvptocnp() at vop_stdvptocnp+0x161/frame 0xfe1247e773e0 > null_vptocnp() at null_vptocnp+0x2b/frame 0xfe1247e77440 > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf7/frame 0xfe1247e77470 > vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfe1247e774e0 > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247e77540 > vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247e77590 > export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247e777c0 > kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame > 0xfe1247e77840 > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame > 0xfe1247e77900 > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame > 0xfe1247e77940 > sysctl_root() at sysctl_root+0x18e/frame 0xfe1247e77990 > userland_sysctl() at userland_sysctl+0x192/frame 0xfe1247e77a30 > sys___sysctl() at sys___sysctl+0x74/frame 0xfe1247e77ae0 > amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247e77bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247e77bf0 > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x801041fca, rsp = > 0x7fffd878, rbp = 0x7fffd8b0 --- > KDB: enter: panic > [ thread pid 1028 tid 100881 ] > Stopped at kdb_enter+0x3e: movq$0,kdb_why > db> call doadump() > > Dump failed. Partition too small. > = 0 -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: r259580 breaks radeonkms
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/08/14 19:38, Konstantin Belousov wrote:
> On Wed, Aug 06, 2014 at 06:52:14PM +0200, Roger Pau Monn?? wrote:
>> On 06/08/14 16:35, Nathan Whitehorn wrote:
>>>
>>>
>>> On 2014-08-06 02:35, Roger Pau Monn?? wrote:
On 06/08/14 02:37, Nathan Whitehorn wrote:
> Kernels with r269580 will panic when loading the radeonkms
> driver in pmap_page_set_memattr(). This probably indicates
> a bug in radeonkms, but the system is unusable in the
> meantime. -Nathan
I seem to be able to load radeonkms just fine after r269580:
>>>
>>> It's possible that it is related to actually using it, rather
>>> than loading the module. I was only testing them together. I'm
>>> using vt and the panic (page fault in kernel mode) occurs when
>>> TTM tries to set memory attributes on some page while starting
>>> X. Before the panic, I see all the normal Radeon module
>>> messages as you do, so the module seems to have actually loaded
>>> correctly. The KMS console also seems to be functional enough
>>> to display the panic message, so I suspect it's X that triggers
>>> it. -Nathan
>>
>> Please try the attached patch, it seems to solve the panic for
>> me. It also includes a fix for Intel i915 gem, which I'm not able
>> to test because I don't have the hardware.
>>
>> Roger.
>>
>
>> From 9dd3a21d99ff2fc7bf3299359751d2399eee912a Mon Sep 17 00:00:00
>> 2001 From: Roger Pau Monne Date: Wed, 6
>> Aug 2014 18:16:53 +0200 Subject: [PATCH] drm: fix usage of
>> vm_phys_fictitious_to_vm_page
>>
>> vm_phys_fictitious_to_vm_page should not be called directly, even
>> when operating on a range that has been registered using
>> vm_phys_fictitious_reg_range. PHYS_TO_VM_PAGE should be used
>> instead because on arches that use VM_PHYSSEG_DENSE the page
>> might come directly from vm_page_array.
>>
>> Reported by: nwhitehorn Sponsored by: Citrix Systems R&D ---
>> sys/dev/drm2/i915/i915_gem.c |6 --
>> sys/dev/drm2/ttm/ttm_bo_vm.c |8 ++-- 2 files changed, 10
>> insertions(+), 4 deletions(-)
>>
>> diff --git a/sys/dev/drm2/i915/i915_gem.c
>> b/sys/dev/drm2/i915/i915_gem.c index a3acb60..6d46207 100644 ---
>> a/sys/dev/drm2/i915/i915_gem.c +++
>> b/sys/dev/drm2/i915/i915_gem.c @@ -1428,8 +1428,10 @@ retry:
>>
>> obj->fault_mappable = true; VM_OBJECT_WLOCK(vm_obj); - m =
>> vm_phys_fictitious_to_vm_page(dev->agp->base + obj->gtt_offset +
>> -offset); + m = PHYS_TO_VM_PAGE(dev->agp->base +
>> obj->gtt_offset + offset); + KASSERT((m->flags & PG_FICTITIOUS)
>> != 0, + ("physical address %#jx not fictitious", +
>> (uintmax_t)(dev->agp->base + obj->gtt_offset + offset))); if (m
>> == NULL) { VM_OBJECT_WUNLOCK(vm_obj); cause = 60; diff --git
>> a/sys/dev/drm2/ttm/ttm_bo_vm.c b/sys/dev/drm2/ttm/ttm_bo_vm.c
>> index 83ec76c..7aa1ac0 100644 --- a/sys/dev/drm2/ttm/ttm_bo_vm.c
>> +++ b/sys/dev/drm2/ttm/ttm_bo_vm.c @@ -216,8 +216,12 @@ reserve:
>> }
>>
>> if (bo->mem.bus.is_iomem) { -m =
>> vm_phys_fictitious_to_vm_page(bo->mem.bus.base + -
>> bo->mem.bus.offset + offset); + m =
>> PHYS_TO_VM_PAGE(bo->mem.bus.base + bo->mem.bus.offset + +
>> offset); + KASSERT((m->flags & PG_FICTITIOUS) != 0, +
>> ("physical address %#jx not fictitious", +
>> (uintmax_t)(bo->mem.bus.base + bo->mem.bus.offset + +
>> offset))); pmap_page_set_memattr(m,
>> ttm_io_prot(bo->mem.placement)); } else { ttm = bo->ttm;
>
> This should be fine. In fact I considered doing similar change
> some time ago, but for some reasons decided not to. Still, it is
> not clear why does it break with your changes, in particular, the
> PCI hole where the aperture is mapped should be covered by
> vm_page_array.
This is because I've changed the logic in
vm_phys_fictitious_reg_range, so that if a region is covered by
vm_page_array it is no longer added to the red-black tree that tracks
fictitious ranges, and thus vm_phys_fictitious_to_vm_page returns NULL
in those cases.
Roger.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (Darwin)
iQEcBAEBAgAGBQJT4mmWAAoJEKXZdqUyumTAEpIH/1c/BgcC0MvlTPTq4yamnGTD
FdoaNABSfh6VRRfAlQjzyTKldVLpXfcZnTpVaHiTNZgT2TRDzFoI3Brawhr33grg
1MDpYS+EusxadkTBYrsV8rQ4+t1K6jCPxgOJPVnB+85ud2Uu6SWJgilfZTW2Raq4
AKlItP2BrKtH0+Fbrtg7rBsz/Knx7kExC7bPHyBBDDuakfZJFhfIn/To1iJgw5Ug
Nmtje8IhEChtZFG9Q3S1IT8Azb8FlnImXaBdwk2bBhjMaeP0jKQFV7a6lpG+4Jjs
3/PeJtgsQpCry7oIZNZ8sCptQSRAx4lSKjgpqoTchowSv1Fj41a0s7IsJ4ALiQ8=
=DbvG
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259580 breaks radeonkms
On Wed, Aug 06, 2014 at 06:52:14PM +0200, Roger Pau Monn?? wrote:
> On 06/08/14 16:35, Nathan Whitehorn wrote:
> >
> >
> > On 2014-08-06 02:35, Roger Pau Monn?? wrote:
> >> On 06/08/14 02:37, Nathan Whitehorn wrote:
> >>> Kernels with r269580 will panic when loading the radeonkms driver in
> >>> pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but
> >>> the system is unusable in the meantime.
> >>> -Nathan
> >>
> >> I seem to be able to load radeonkms just fine after r269580:
> >
> > It's possible that it is related to actually using it, rather than
> > loading the module. I was only testing them together. I'm using vt and
> > the panic (page fault in kernel mode) occurs when TTM tries to set
> > memory attributes on some page while starting X. Before the panic, I see
> > all the normal Radeon module messages as you do, so the module seems to
> > have actually loaded correctly. The KMS console also seems to be
> > functional enough to display the panic message, so I suspect it's X that
> > triggers it.
> > -Nathan
>
> Please try the attached patch, it seems to solve the panic for me. It
> also includes a fix for Intel i915 gem, which I'm not able to test
> because I don't have the hardware.
>
> Roger.
>
> From 9dd3a21d99ff2fc7bf3299359751d2399eee912a Mon Sep 17 00:00:00 2001
> From: Roger Pau Monne
> Date: Wed, 6 Aug 2014 18:16:53 +0200
> Subject: [PATCH] drm: fix usage of vm_phys_fictitious_to_vm_page
>
> vm_phys_fictitious_to_vm_page should not be called directly, even when
> operating on a range that has been registered using
> vm_phys_fictitious_reg_range. PHYS_TO_VM_PAGE should be used instead
> because on arches that use VM_PHYSSEG_DENSE the page might come
> directly from vm_page_array.
>
> Reported by: nwhitehorn
> Sponsored by: Citrix Systems R&D
> ---
> sys/dev/drm2/i915/i915_gem.c |6 --
> sys/dev/drm2/ttm/ttm_bo_vm.c |8 ++--
> 2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c
> index a3acb60..6d46207 100644
> --- a/sys/dev/drm2/i915/i915_gem.c
> +++ b/sys/dev/drm2/i915/i915_gem.c
> @@ -1428,8 +1428,10 @@ retry:
>
> obj->fault_mappable = true;
> VM_OBJECT_WLOCK(vm_obj);
> - m = vm_phys_fictitious_to_vm_page(dev->agp->base + obj->gtt_offset +
> - offset);
> + m = PHYS_TO_VM_PAGE(dev->agp->base + obj->gtt_offset + offset);
> + KASSERT((m->flags & PG_FICTITIOUS) != 0,
> + ("physical address %#jx not fictitious",
> + (uintmax_t)(dev->agp->base + obj->gtt_offset + offset)));
> if (m == NULL) {
> VM_OBJECT_WUNLOCK(vm_obj);
> cause = 60;
> diff --git a/sys/dev/drm2/ttm/ttm_bo_vm.c b/sys/dev/drm2/ttm/ttm_bo_vm.c
> index 83ec76c..7aa1ac0 100644
> --- a/sys/dev/drm2/ttm/ttm_bo_vm.c
> +++ b/sys/dev/drm2/ttm/ttm_bo_vm.c
> @@ -216,8 +216,12 @@ reserve:
> }
>
> if (bo->mem.bus.is_iomem) {
> - m = vm_phys_fictitious_to_vm_page(bo->mem.bus.base +
> - bo->mem.bus.offset + offset);
> + m = PHYS_TO_VM_PAGE(bo->mem.bus.base + bo->mem.bus.offset +
> + offset);
> + KASSERT((m->flags & PG_FICTITIOUS) != 0,
> + ("physical address %#jx not fictitious",
> + (uintmax_t)(bo->mem.bus.base + bo->mem.bus.offset
> + + offset)));
> pmap_page_set_memattr(m, ttm_io_prot(bo->mem.placement));
> } else {
> ttm = bo->ttm;
This should be fine. In fact I considered doing similar change some
time ago, but for some reasons decided not to. Still, it is not clear
why does it break with your changes, in particular, the PCI hole
where the aperture is mapped should be covered by vm_page_array.
pgpmQClPVye6N.pgp
Description: PGP signature
Re: r259580 breaks radeonkms
> On Aug 6, 2014, at 9:52, Roger Pau Monné wrote: > >> On 06/08/14 16:35, Nathan Whitehorn wrote: >> >> >>> On 2014-08-06 02:35, Roger Pau Monné wrote: On 06/08/14 02:37, Nathan Whitehorn wrote: Kernels with r269580 will panic when loading the radeonkms driver in pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but the system is unusable in the meantime. -Nathan >>> >>> I seem to be able to load radeonkms just fine after r269580: >> >> It's possible that it is related to actually using it, rather than >> loading the module. I was only testing them together. I'm using vt and >> the panic (page fault in kernel mode) occurs when TTM tries to set >> memory attributes on some page while starting X. Before the panic, I see >> all the normal Radeon module messages as you do, so the module seems to >> have actually loaded correctly. The KMS console also seems to be >> functional enough to display the panic message, so I suspect it's X that >> triggers it. >> -Nathan > > Please try the attached patch, it seems to solve the panic for me. It > also includes a fix for Intel i915 gem, which I'm not able to test > because I don't have the hardware. > > Roger. > > <0001-drm-fix-usage-of-vm_phys_fictitious_to_vm_page.patch> David McKay confirmed that the patch worked for them on an intel GEM compatible chipset. Cheers! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259580 breaks radeonkms
On 08/06/14 09:52, Roger Pau Monné wrote: On 06/08/14 16:35, Nathan Whitehorn wrote: On 2014-08-06 02:35, Roger Pau Monné wrote: On 06/08/14 02:37, Nathan Whitehorn wrote: Kernels with r269580 will panic when loading the radeonkms driver in pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but the system is unusable in the meantime. -Nathan I seem to be able to load radeonkms just fine after r269580: It's possible that it is related to actually using it, rather than loading the module. I was only testing them together. I'm using vt and the panic (page fault in kernel mode) occurs when TTM tries to set memory attributes on some page while starting X. Before the panic, I see all the normal Radeon module messages as you do, so the module seems to have actually loaded correctly. The KMS console also seems to be functional enough to display the panic message, so I suspect it's X that triggers it. -Nathan Please try the attached patch, it seems to solve the panic for me. It also includes a fix for Intel i915 gem, which I'm not able to test because I don't have the hardware. Roger. Works for me on radeon. Thanks! -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: aatpic_assign_cpu: bad cookie [Was: Build machine OK; laptop panics @r269515]
On Tue, 5 Aug 2014 20:49-0700, John Baldwin wrote: > > On Aug 5, 2014, at 2:29 PM, Michael Butler > wrote: > > > On 08/05/14 16:56, Michael Butler wrote: > >> On 08/05/14 16:02, John Baldwin wrote: > >> > >>> My guess is that the recent Xen changes tickled something. > >> > >> I can confirm this on a kernel which is otherwise up to date .. > >> > >> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD > >> 11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014 > >> > >> I backed out all of SVN r269507 through r269515. > >> > >> Now working .. > > > > [ .. snip .. ] > > > >> Now to see if it's related to the other machine's disk woes (it's a > >> single-core device), > > > > And it fixes the inability to probe disks on my single-core machine :-) > > It looks like the MADT code to probe the I/O APICs isn't working so > it's trying to fall back to using the ATPIC while using SMP (which > doesn't work). I know it's a pain on a laptop, but if it is at all > possible to capture either a verbose or non-verbose dmesg that would > really help narrow it down. > > Also, if anyone can try reverting just the MADT-related changes in > the recent Xen changes to see if you can narrow down which exact one > triggers the panic that would be really helpful. I noticed this panic on i386 head r269607 yesterday, running in VBox on Windows 7 SP1 x64, on an Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz (3175.67-MHz 686-class CPU). Go to http://ximalas.info/~trond/atpic_assign_cpu/ where you'll find a verbose dmesg from i386 head r268838 from the same VM and a couple of screenshots of the crash while booting r269607 with the verbose flag on. I'm rewinding /usr/src to r269507, and I'll take it from there, one commit at the time. I'll also try to investigate this panic using my amd64 head VM. -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259580 breaks radeonkms
On 06/08/14 16:35, Nathan Whitehorn wrote:
>
>
> On 2014-08-06 02:35, Roger Pau Monné wrote:
>> On 06/08/14 02:37, Nathan Whitehorn wrote:
>>> Kernels with r269580 will panic when loading the radeonkms driver in
>>> pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but
>>> the system is unusable in the meantime.
>>> -Nathan
>>
>> I seem to be able to load radeonkms just fine after r269580:
>
> It's possible that it is related to actually using it, rather than
> loading the module. I was only testing them together. I'm using vt and
> the panic (page fault in kernel mode) occurs when TTM tries to set
> memory attributes on some page while starting X. Before the panic, I see
> all the normal Radeon module messages as you do, so the module seems to
> have actually loaded correctly. The KMS console also seems to be
> functional enough to display the panic message, so I suspect it's X that
> triggers it.
> -Nathan
Please try the attached patch, it seems to solve the panic for me. It
also includes a fix for Intel i915 gem, which I'm not able to test
because I don't have the hardware.
Roger.
From 9dd3a21d99ff2fc7bf3299359751d2399eee912a Mon Sep 17 00:00:00 2001
From: Roger Pau Monne
Date: Wed, 6 Aug 2014 18:16:53 +0200
Subject: [PATCH] drm: fix usage of vm_phys_fictitious_to_vm_page
vm_phys_fictitious_to_vm_page should not be called directly, even when
operating on a range that has been registered using
vm_phys_fictitious_reg_range. PHYS_TO_VM_PAGE should be used instead
because on arches that use VM_PHYSSEG_DENSE the page might come
directly from vm_page_array.
Reported by: nwhitehorn
Sponsored by: Citrix Systems R&D
---
sys/dev/drm2/i915/i915_gem.c |6 --
sys/dev/drm2/ttm/ttm_bo_vm.c |8 ++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c
index a3acb60..6d46207 100644
--- a/sys/dev/drm2/i915/i915_gem.c
+++ b/sys/dev/drm2/i915/i915_gem.c
@@ -1428,8 +1428,10 @@ retry:
obj->fault_mappable = true;
VM_OBJECT_WLOCK(vm_obj);
- m = vm_phys_fictitious_to_vm_page(dev->agp->base + obj->gtt_offset +
- offset);
+ m = PHYS_TO_VM_PAGE(dev->agp->base + obj->gtt_offset + offset);
+ KASSERT((m->flags & PG_FICTITIOUS) != 0,
+ ("physical address %#jx not fictitious",
+ (uintmax_t)(dev->agp->base + obj->gtt_offset + offset)));
if (m == NULL) {
VM_OBJECT_WUNLOCK(vm_obj);
cause = 60;
diff --git a/sys/dev/drm2/ttm/ttm_bo_vm.c b/sys/dev/drm2/ttm/ttm_bo_vm.c
index 83ec76c..7aa1ac0 100644
--- a/sys/dev/drm2/ttm/ttm_bo_vm.c
+++ b/sys/dev/drm2/ttm/ttm_bo_vm.c
@@ -216,8 +216,12 @@ reserve:
}
if (bo->mem.bus.is_iomem) {
- m = vm_phys_fictitious_to_vm_page(bo->mem.bus.base +
- bo->mem.bus.offset + offset);
+ m = PHYS_TO_VM_PAGE(bo->mem.bus.base + bo->mem.bus.offset +
+ offset);
+ KASSERT((m->flags & PG_FICTITIOUS) != 0,
+ ("physical address %#jx not fictitious",
+ (uintmax_t)(bo->mem.bus.base + bo->mem.bus.offset
+ + offset)));
pmap_page_set_memattr(m, ttm_io_prot(bo->mem.placement));
} else {
ttm = bo->ttm;
--
1.7.7.5 (Apple Git-26)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Xorg failure (segfault after vm_error: pager read error, pid 1562 (Xorg)) on Amd64
Hello, Today I undertook to update my kernel and world, last built on July the 5th, to the latest -CURRENT sources from svn. Upon starting Xorg, this error emerged: vm_error: pager read error, pid 1562 (Xorg) Segmentation fault at address 0x80081e000 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting I am running on a Lenovo ThinkPad W530 with Intel IvyBridge graphics via KMS. Thanks, David Mackay ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Xorg failure (segfault after vm_error: pager read error, pid 1562 (Xorg)) on Amd64
On Aug 6, 2014, at 9:18 AM, David Mackay wrote: > Hello, > > Today I undertook to update my kernel and world, last built on July > the 5th, to the latest -CURRENT sources from svn. > > Upon starting Xorg, this error emerged: > > vm_error: pager read error, pid 1562 (Xorg) > Segmentation fault at address 0x80081e000 > > Fatal server error: > Caught signal 11 (Segmentation fault). Server aborting > > I am running on a Lenovo ThinkPad W530 with Intel IvyBridge graphics via KMS. Hi David, Have you read this thread yet: http://lists.freebsd.org/pipermail/freebsd-current/2014-August/051554.html ? Cheers! -Garrett signature.asc Description: Message signed with OpenPGP using GPGMail
Re: r259580 breaks radeonkms
On 2014-08-06 02:35, Roger Pau Monné wrote: On 06/08/14 02:37, Nathan Whitehorn wrote: Kernels with r269580 will panic when loading the radeonkms driver in pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but the system is unusable in the meantime. -Nathan I seem to be able to load radeonkms just fine after r269580: It's possible that it is related to actually using it, rather than loading the module. I was only testing them together. I'm using vt and the panic (page fault in kernel mode) occurs when TTM tries to set memory attributes on some page while starting X. Before the panic, I see all the normal Radeon module messages as you do, so the module seems to have actually loaded correctly. The KMS console also seems to be functional enough to display the panic message, so I suspect it's X that triggers it. -Nathan # kldload radeonkms info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 276 to local APIC 0 vector 48 vgapci0: using IRQ 276 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] RADEON_IS_PCIE info: [drm] initializing kernel modesetting (RV620 0x1002:0x95CF 0x1002:0x2143). info: [drm] register mmio base: 0xF7DF info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:2:0:0, vendor=1002, device=95cf info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xe000 info: [drm] igp_read_bios_from_vram: Map address: 0xf800e000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x200F info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xf80c (131072 bytes) info: [drm] ATOM BIOS: 113 drmn0: info: VRAM: 256M 0x - 0x0FFF (256M used) drmn0: info: GTT: 512M 0x1000 - 0x2FFF info: [drm] Detected VRAM RAM=256M, BAR=256M info: [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 3129302 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 256M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] probing gen 2 caps for device 8086:340a = 2/0 info: [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 info: [drm] Loading RV620 Microcode firmware: 'radeonkmsfw_RV620_pfp' version 0: 2304 bytes loaded at 0x8214b0d0 firmware: 'radeonkmsfw_RV620_me' version 0: 21504 bytes loaded at 0x8214d0d0 firmware: 'radeonkmsfw_R600_rlc' version 0: 3072 bytes loaded at 0x821530d0 info: [drm] PCIE GART of 512M enabled (table at 0x0004). drmn0: info: WB enabled drmn0: info: fence driver on ring 0 use gpu addr 0x1c00 and cpu addr 0x0xf80058ab6c00 drmn0: info: fence driver on ring 3 use gpu addr 0x1c0c and cpu addr 0x0xf80058ab6c0c info: [drm] ring test on 0 succeeded in 0 usecs info: [drm] ring test on 3 succeeded in 1 usecs info: [drm] ib test on ring 0 succeeded in 0 usecs info: [drm] ib test on ring 3 succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xe000-0xf000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0x0 iic1: on iicbus1 iicbus2: on iicbb2 addr 0x0 iic2: on iicbus2 iicbus3: on iicbb3 addr 0x0 iic3: on iicbus3 iicbus4: on iicbb4 addr 0x0 iic4: on iicbus4 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] DP-1 info: [drm] HPD2 info: [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c info: [drm] Encoders: info: [drm] DFP1: INTERNAL_UNIPHY info: [drm] Connector 1: info: [drm] DP-2 info: [drm] HPD4 info: [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c info: [drm] Encoders: info: [drm] DFP2: INTERNAL_UNIPHY info: [drm] Internal thermal controller with fan control info: [drm] radeon: power management initialized info: [drm] fb mappable at 0xE0142000 info: [drm] vram apper at 0xE000 info: [drm] size 7299072 info: [drm] fb depth is 24 info: [drm]pitch is 6912 fbd0 on drmn0 info: [drm] Initialized radeon 2.29.0 20080528 Although this is a headless server and still using sc. Can you post the output when loading the module? Roger. __
Re: r259580 breaks radeonkms
Something is wrong with Intel hardware too on CURRENT from yesterday. I have not looked deeper into it. Michael ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r259580 breaks radeonkms
On 06/08/14 02:37, Nathan Whitehorn wrote: > Kernels with r269580 will panic when loading the radeonkms driver in > pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but > the system is unusable in the meantime. > -Nathan I seem to be able to load radeonkms just fine after r269580: # kldload radeonkms info: [drm] Initialized drm 1.1.0 20060810 drmn0: on vgapci0 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 276 to local APIC 0 vector 48 vgapci0: using IRQ 276 for MSI info: [drm] MSI enabled 1 message(s) info: [drm] RADEON_IS_PCIE info: [drm] initializing kernel modesetting (RV620 0x1002:0x95CF 0x1002:0x2143). info: [drm] register mmio base: 0xF7DF info: [drm] register mmio size: 65536 info: [drm] radeon_atrm_get_bios: ===> Try ATRM... info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:2:0:0, vendor=1002, device=95cf info: [drm] radeon_atrm_get_bios: Get ACPI device handle info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT... info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM... info: [drm] igp_read_bios_from_vram: VRAM base address: 0xe000 info: [drm] igp_read_bios_from_vram: Map address: 0xf800e000 (262144 bytes) info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x200F info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM... info: [drm] radeon_read_bios: Map address: 0xf80c (131072 bytes) info: [drm] ATOM BIOS: 113 drmn0: info: VRAM: 256M 0x - 0x0FFF (256M used) drmn0: info: GTT: 512M 0x1000 - 0x2FFF info: [drm] Detected VRAM RAM=256M, BAR=256M info: [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 3129302 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator info: [drm] radeon: 256M of VRAM memory ready info: [drm] radeon: 512M of GTT memory ready. info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] GART: num cpu pages 131072, num gpu pages 131072 info: [drm] probing gen 2 caps for device 8086:340a = 2/0 info: [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 info: [drm] Loading RV620 Microcode firmware: 'radeonkmsfw_RV620_pfp' version 0: 2304 bytes loaded at 0x8214b0d0 firmware: 'radeonkmsfw_RV620_me' version 0: 21504 bytes loaded at 0x8214d0d0 firmware: 'radeonkmsfw_R600_rlc' version 0: 3072 bytes loaded at 0x821530d0 info: [drm] PCIE GART of 512M enabled (table at 0x0004). drmn0: info: WB enabled drmn0: info: fence driver on ring 0 use gpu addr 0x1c00 and cpu addr 0x0xf80058ab6c00 drmn0: info: fence driver on ring 3 use gpu addr 0x1c0c and cpu addr 0x0xf80058ab6c0c info: [drm] ring test on 0 succeeded in 0 usecs info: [drm] ring test on 3 succeeded in 1 usecs info: [drm] ib test on ring 0 succeeded in 0 usecs info: [drm] ib test on ring 3 succeeded in 0 usecs info: [drm] radeon_device_init: Taking over the fictitious range 0xe000-0xf000 iicbus0: on iicbb0 addr 0xff iic0: on iicbus0 iicbus1: on iicbb1 addr 0x0 iic1: on iicbus1 iicbus2: on iicbb2 addr 0x0 iic2: on iicbus2 iicbus3: on iicbb3 addr 0x0 iic3: on iicbus3 iicbus4: on iicbb4 addr 0x0 iic4: on iicbus4 info: [drm] Radeon Display Connectors info: [drm] Connector 0: info: [drm] DP-1 info: [drm] HPD2 info: [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c info: [drm] Encoders: info: [drm] DFP1: INTERNAL_UNIPHY info: [drm] Connector 1: info: [drm] DP-2 info: [drm] HPD4 info: [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c info: [drm] Encoders: info: [drm] DFP2: INTERNAL_UNIPHY info: [drm] Internal thermal controller with fan control info: [drm] radeon: power management initialized info: [drm] fb mappable at 0xE0142000 info: [drm] vram apper at 0xE000 info: [drm] size 7299072 info: [drm] fb depth is 24 info: [drm]pitch is 6912 fbd0 on drmn0 info: [drm] Initialized radeon 2.29.0 20080528 Although this is a headless server and still using sc. Can you post the output when loading the module? Roger. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
