Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Thu, 21 Mar 2013 20:31:06 +0200 Konstantin Belousov kostik...@gmail.com wrote: On Thu, Mar 21, 2013 at 07:14:26PM +0100, Gary Jennejohn wrote: I wonder whether there isn't some dependency on the graphics chip being used. I'm running r248589 AMD64 and didn't have to touch a thing to get X to start. But I'm using an older, presumably less demanding graphics chip: You use the amd64 kernel, which has ample KVA space. The problem is specific to i386. vgapci0@pci0:1:0:0: class=0x03 card=0x19051462 chip=0x0a6510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GT218 [GeForce 210]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xfb00, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xc000, size 268435456, enabled bar [1c] = type Prefetchable Memory, range 64, base 0xde00, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xef00, size 128, enabled Above all, bar [14] is only half as large. In the part you deleted Shawn Webb reports that he's also using AMD64. -- Gary Jennejohn ___ 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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 06:36:10PM -0700, David Wolfskill wrote: I elected to go ahead and try the bisection; here are my results: r248493M/248493: OK r248550M/248551: resets on X startup with nvidia.ko r248521M/248521: resets on X startup with nvidia.ko r248507M/248507: OK r248508M/248508: resets on X startup with nvidia.ko r248493M/248493 was my last working point (built yesterday morning). r248550M/248551 was what failed for me this morning. r248521M/248521 was a convenient mid-point between the above two. r248507M/248507 was the next natural test-point. r248508M/248508 was a guess on my part -- I would normally have gone to r248514, but since I had previously noted that r248508 touched some things that nvidia-driver uses, I thought that test might be worthwhile. I am, however, mildly concerned that no one else appears to be reporting similar symptoms (though I have it on good authority that someone is about to test). This gives me an idea. The only so to say 'vm' change in r248508 was an addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed tunable did not eliminated the submap creation. Please try r248569 with vfs.unmapped_buf_allowed set to 0. If this combination allows the nvidia driver to start, please revert the setting of vfs.unmapped_buf_allowed, and instead set kern.bio_transient_maxcnt e.g. to 256 or even 128. Also, on the machine without the tunables customization, please show the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show the output of pciconf -lvb. From what I see in your report, you use i386 arch. What is the amount of memory installed in the machine ? pgphmgNqT7ZDG.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On 21.03.2013 09:04, Konstantin Belousov wrote: On Wed, Mar 20, 2013 at 06:36:10PM -0700, David Wolfskill wrote: I elected to go ahead and try the bisection; here are my results: r248493M/248493: OK r248550M/248551: resets on X startup with nvidia.ko r248521M/248521: resets on X startup with nvidia.ko r248507M/248507: OK r248508M/248508: resets on X startup with nvidia.ko r248493M/248493 was my last working point (built yesterday morning). r248550M/248551 was what failed for me this morning. r248521M/248521 was a convenient mid-point between the above two. r248507M/248507 was the next natural test-point. r248508M/248508 was a guess on my part -- I would normally have gone to r248514, but since I had previously noted that r248508 touched some things that nvidia-driver uses, I thought that test might be worthwhile. I am, however, mildly concerned that no one else appears to be reporting similar symptoms (though I have it on good authority that someone is about to test). This gives me an idea. The only so to say 'vm' change in r248508 was an addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed tunable did not eliminated the submap creation. Please try r248569 with vfs.unmapped_buf_allowed set to 0. If this combination allows the nvidia driver to start, please revert the setting of vfs.unmapped_buf_allowed, and instead set kern.bio_transient_maxcnt e.g. to 256 or even 128. Also, on the machine without the tunables customization, please show the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show the output of pciconf -lvb. To be able to have kernel core dumps while X.Org is running, I need to set the debug.debugger_on_panic=0 sysctl. Otherwise, the computer only reboots (it doesn't honor the ddb script). Maybe it can help here? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Thu, Mar 21, 2013 at 10:04:41AM +0200, Konstantin Belousov wrote: ... This gives me an idea. The only so to say 'vm' change in r248508 was an addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed tunable did not eliminated the submap creation. Please try r248569 with vfs.unmapped_buf_allowed set to 0. OK; I believe that worked. Believe because (in the normal course of things) I updated to: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 which is a little beyond r248569. (I still have r248508 on a different slice, and figured I could update that to precisely r248569 if this test was incorrect or inconclusive.) In any case: after booting the above (r248575) to verify that it worked as long as I did not load nvidia.ko first, I then rebooted, escaped to loader prompt, set vfs.unmapped_buf_allowed=0; boot. And after that came up OK, I (manually) loaded nvidia.ko, then re-started X (xdm); the nVidia banner displayed just before the xdm login screen did. (I have my xdm startup script prefer the nvidia driver, but if nvidia.ko isn't loaded, it reverts to the nv driver automagically.) If this combination allows the nvidia driver to start, please revert the setting of vfs.unmapped_buf_allowed, and instead set kern.bio_transient_maxcnt e.g. to 256 or even 128. OK; rebooting, escaping to loader, *not* setting vfs.unmapped_buf_allowed, and setting kern.bio_transient_maxcnt=256 also allowed nvidia driver to be used at r248575. Also, on the machine without the tunables customization, please show the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show the output of pciconf -lvb. OK; I rebooted (to revert the vfs.unmapped_buf_allowed setting) and obtained the above (augmented a wee bit by some of the others mentioned; I've attached that as sysctl.txt. I've also attached a copy of dmesg.boot, in case that's useful. I then tried rebooting r248575 and loading nvidia.ko *without* the tunable customization, and verified that I still saw (what looks like) a reset when I start X that way (as reported initially). From what I see in your report, you use i386 arch. What is the amount of memory installed in the machine ? 4GB. Is the above what you had in mind, or would you like me to try at precisely r248569? Anything else? Thanks again! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. Script started on Thu Mar 21 06:07:41 2013 g1-235(10.0-C)[1] uname -a FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed kern.bio_transient_maxcnt kern.nbuf vfs.unmapped_buf_allowed: 1 kern.bio_transient_maxcnt: 697 kern.nbuf: 7224 g1-235(10.0-C)[3] pciconf -lvb hostb0@pci0:0:0:0: class=0x06 card=0x02501028 chip=0x2a408086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Memory Controller Hub' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x02501028 chip=0x2a418086 rev=0x07 hdr=0x01 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset PCI Express Graphics Port' class = bridge subclass = PCI-PCI none0@pci0:0:3:0: class=0x078000 card=0x02501028 chip=0x2a448086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset MEI Controller' class = simple comms bar [10] = type Memory, range 64, base 0xf6fd9ef0, size 16, enabled atapci0@pci0:0:3:2: class=0x010185 card=0x02501028 chip=0x2a468086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset PT IDER Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xef78, size 8, enabled bar [14] = type I/O Port, range 32, base 0xef70, size 4, enabled bar [18] = type I/O Port, range 32, base 0xef80, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xef74, size 4, enabled bar [20] = type I/O Port, range 32, base 0xef90, size 16, enabled none1@pci0:0:3:3: class=0x070002 card=0x02501028 chip=0x2a478086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset AMT SOL Redirection' class = simple comms subclass = UART bar [10] = type I/O Port, range 32, base 0xef88, size 8, enabled bar [14] = type Memory, range 32, base 0xf6fda000, size 4096, enabled em0@pci0:0:25:0:class=0x02 card=0x02501028 chip=0x10f58086 rev=0x03 hdr=0x00 vendor = 'Intel
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Thu, Mar 21, 2013 at 06:34:46AM -0700, David Wolfskill wrote: On Thu, Mar 21, 2013 at 10:04:41AM +0200, Konstantin Belousov wrote: ... This gives me an idea. The only so to say 'vm' change in r248508 was an addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed tunable did not eliminated the submap creation. Please try r248569 with vfs.unmapped_buf_allowed set to 0. OK; I believe that worked. Believe because (in the normal course of things) I updated to: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 which is a little beyond r248569. (I still have r248508 on a different slice, and figured I could update that to precisely r248569 if this test was incorrect or inconclusive.) Not needed. BTW, your system uses UFS, right ? In any case: after booting the above (r248575) to verify that it worked as long as I did not load nvidia.ko first, I then rebooted, escaped to loader prompt, set vfs.unmapped_buf_allowed=0; boot. And after that came up OK, I (manually) loaded nvidia.ko, then re-started X (xdm); the nVidia banner displayed just before the xdm login screen did. (I have my xdm startup script prefer the nvidia driver, but if nvidia.ko isn't loaded, it reverts to the nv driver automagically.) If this combination allows the nvidia driver to start, please revert the setting of vfs.unmapped_buf_allowed, and instead set kern.bio_transient_maxcnt e.g. to 256 or even 128. OK; rebooting, escaping to loader, *not* setting vfs.unmapped_buf_allowed, and setting kern.bio_transient_maxcnt=256 also allowed nvidia driver to be used at r248575. Ok, this is almost not a workaround but a solution (for now). See below. Also, on the machine without the tunables customization, please show the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show the output of pciconf -lvb. OK; I rebooted (to revert the vfs.unmapped_buf_allowed setting) and obtained the above (augmented a wee bit by some of the others mentioned; I've attached that as sysctl.txt. I've also attached a copy of dmesg.boot, in case that's useful. I then tried rebooting r248575 and loading nvidia.ko *without* the tunable customization, and verified that I still saw (what looks like) a reset when I start X that way (as reported initially). From what I see in your report, you use i386 arch. What is the amount of memory installed in the machine ? 4GB. Is the above what you had in mind, or would you like me to try at precisely r248569? Anything else? r248569 is fine. Script started on Thu Mar 21 06:07:41 2013 g1-235(10.0-C)[1] uname -a FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed kern.bio_transient_maxcnt kern.nbuf vfs.unmapped_buf_allowed: 1 kern.bio_transient_maxcnt: 697 kern.nbuf: 7224 Could you, please, do some more measurements in the r248575M ? Please show the kern.nbuf for vfs.unmapped_buf_allowed=0 case. Also, from there, run kgdb /boot/kernel/kernel /dev/mem and do p *buffer_map. Reboot without applying any unmapped/transient tuning, run the kgdb again, and do p *buffer_map p *bio_transient_map Reboot with kern.bio_transient_maxcnt tunable set to 256 and again print the buffer_map and bio_transient_map from the kgdb. none1@pci0:0:3:3: class=0x070002 card=0x02501028 chip=0x2a478086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset AMT SOL Redirection' class = simple comms subclass = UART bar [10] = type I/O Port, range 32, base 0xef88, size 8, enabled bar [14] = type Memory, range 32, base 0xf6fda000, size 4096, enabled Oh, you do have the serial port on your notebook, usable remotely without serial cable. Your chipset seems to be AMT-capable, and you could use comms/amtterm from other machine to get a serial console. vgapci0@pci0:1:0:0: class=0x03 card=0x02501028 chip=0x065c10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'G96M [Quadro FX 770M]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xf500, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xe000, size 268435456, enabled bar [1c] = type Memory, range 64, base 0xf200, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled My current theory is that the nvidia aperture size is 256MB, as indicated by bar at 14, and nvidia driver tries to map the whole aperture into KVA. With 4GB of RAM and i386, available 1GB of the KVA become quite tightly populated, and even small changes in the
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Thu, Mar 21, 2013 at 9:58 AM, Konstantin Belousov kostik...@gmail.comwrote: On Thu, Mar 21, 2013 at 06:34:46AM -0700, David Wolfskill wrote: On Thu, Mar 21, 2013 at 10:04:41AM +0200, Konstantin Belousov wrote: ... This gives me an idea. The only so to say 'vm' change in r248508 was an addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed tunable did not eliminated the submap creation. Please try r248569 with vfs.unmapped_buf_allowed set to 0. OK; I believe that worked. Believe because (in the normal course of things) I updated to: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 which is a little beyond r248569. (I still have r248508 on a different slice, and figured I could update that to precisely r248569 if this test was incorrect or inconclusive.) Not needed. BTW, your system uses UFS, right ? In any case: after booting the above (r248575) to verify that it worked as long as I did not load nvidia.ko first, I then rebooted, escaped to loader prompt, set vfs.unmapped_buf_allowed=0; boot. And after that came up OK, I (manually) loaded nvidia.ko, then re-started X (xdm); the nVidia banner displayed just before the xdm login screen did. (I have my xdm startup script prefer the nvidia driver, but if nvidia.ko isn't loaded, it reverts to the nv driver automagically.) If this combination allows the nvidia driver to start, please revert the setting of vfs.unmapped_buf_allowed, and instead set kern.bio_transient_maxcnt e.g. to 256 or even 128. OK; rebooting, escaping to loader, *not* setting vfs.unmapped_buf_allowed, and setting kern.bio_transient_maxcnt=256 also allowed nvidia driver to be used at r248575. Ok, this is almost not a workaround but a solution (for now). See below. Also, on the machine without the tunables customization, please show the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show the output of pciconf -lvb. OK; I rebooted (to revert the vfs.unmapped_buf_allowed setting) and obtained the above (augmented a wee bit by some of the others mentioned; I've attached that as sysctl.txt. I've also attached a copy of dmesg.boot, in case that's useful. I then tried rebooting r248575 and loading nvidia.ko *without* the tunable customization, and verified that I still saw (what looks like) a reset when I start X that way (as reported initially). From what I see in your report, you use i386 arch. What is the amount of memory installed in the machine ? 4GB. Is the above what you had in mind, or would you like me to try at precisely r248569? Anything else? r248569 is fine. Script started on Thu Mar 21 06:07:41 2013 g1-235(10.0-C)[1] uname -a FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed kern.bio_transient_maxcnt kern.nbuf vfs.unmapped_buf_allowed: 1 kern.bio_transient_maxcnt: 697 kern.nbuf: 7224 Could you, please, do some more measurements in the r248575M ? Please show the kern.nbuf for vfs.unmapped_buf_allowed=0 case. Also, from there, run kgdb /boot/kernel/kernel /dev/mem and do p *buffer_map. Reboot without applying any unmapped/transient tuning, run the kgdb again, and do p *buffer_map p *bio_transient_map Reboot with kern.bio_transient_maxcnt tunable set to 256 and again print the buffer_map and bio_transient_map from the kgdb. none1@pci0:0:3:3: class=0x070002 card=0x02501028 chip=0x2a478086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset AMT SOL Redirection' class = simple comms subclass = UART bar [10] = type I/O Port, range 32, base 0xef88, size 8, enabled bar [14] = type Memory, range 32, base 0xf6fda000, size 4096, enabled Oh, you do have the serial port on your notebook, usable remotely without serial cable. Your chipset seems to be AMT-capable, and you could use comms/amtterm from other machine to get a serial console. vgapci0@pci0:1:0:0: class=0x03 card=0x02501028 chip=0x065c10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'G96M [Quadro FX 770M]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xf500, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xe000, size 268435456, enabled bar [1c] = type Memory, range 64, base 0xf200, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled My current theory is that the nvidia aperture size is 256MB, as indicated by bar at 14, and nvidia driver tries to map
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Thu, Mar 21, 2013 at 12:04 PM, Shawn Webb latt...@gmail.com wrote: On Thu, Mar 21, 2013 at 9:58 AM, Konstantin Belousov kostik...@gmail.comwrote: On Thu, Mar 21, 2013 at 06:34:46AM -0700, David Wolfskill wrote: On Thu, Mar 21, 2013 at 10:04:41AM +0200, Konstantin Belousov wrote: ... This gives me an idea. The only so to say 'vm' change in r248508 was an addition of the bio_transient_map submap. The vfs.unmapped_buf_allowed tunable did not eliminated the submap creation. Please try r248569 with vfs.unmapped_buf_allowed set to 0. OK; I believe that worked. Believe because (in the normal course of things) I updated to: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 which is a little beyond r248569. (I still have r248508 on a different slice, and figured I could update that to precisely r248569 if this test was incorrect or inconclusive.) Not needed. BTW, your system uses UFS, right ? In any case: after booting the above (r248575) to verify that it worked as long as I did not load nvidia.ko first, I then rebooted, escaped to loader prompt, set vfs.unmapped_buf_allowed=0; boot. And after that came up OK, I (manually) loaded nvidia.ko, then re-started X (xdm); the nVidia banner displayed just before the xdm login screen did. (I have my xdm startup script prefer the nvidia driver, but if nvidia.ko isn't loaded, it reverts to the nv driver automagically.) If this combination allows the nvidia driver to start, please revert the setting of vfs.unmapped_buf_allowed, and instead set kern.bio_transient_maxcnt e.g. to 256 or even 128. OK; rebooting, escaping to loader, *not* setting vfs.unmapped_buf_allowed, and setting kern.bio_transient_maxcnt=256 also allowed nvidia driver to be used at r248575. Ok, this is almost not a workaround but a solution (for now). See below. Also, on the machine without the tunables customization, please show the output of sysctl kern.nbuf, kern.bio_transient_maxcnt. Also show the output of pciconf -lvb. OK; I rebooted (to revert the vfs.unmapped_buf_allowed setting) and obtained the above (augmented a wee bit by some of the others mentioned; I've attached that as sysctl.txt. I've also attached a copy of dmesg.boot, in case that's useful. I then tried rebooting r248575 and loading nvidia.ko *without* the tunable customization, and verified that I still saw (what looks like) a reset when I start X that way (as reported initially). From what I see in your report, you use i386 arch. What is the amount of memory installed in the machine ? 4GB. Is the above what you had in mind, or would you like me to try at precisely r248569? Anything else? r248569 is fine. Script started on Thu Mar 21 06:07:41 2013 g1-235(10.0-C)[1] uname -a FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845 r248575M/248575: Thu Mar 21 05:35:06 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed kern.bio_transient_maxcnt kern.nbuf vfs.unmapped_buf_allowed: 1 kern.bio_transient_maxcnt: 697 kern.nbuf: 7224 Could you, please, do some more measurements in the r248575M ? Please show the kern.nbuf for vfs.unmapped_buf_allowed=0 case. Also, from there, run kgdb /boot/kernel/kernel /dev/mem and do p *buffer_map. Reboot without applying any unmapped/transient tuning, run the kgdb again, and do p *buffer_map p *bio_transient_map Reboot with kern.bio_transient_maxcnt tunable set to 256 and again print the buffer_map and bio_transient_map from the kgdb. none1@pci0:0:3:3: class=0x070002 card=0x02501028 chip=0x2a478086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset AMT SOL Redirection' class = simple comms subclass = UART bar [10] = type I/O Port, range 32, base 0xef88, size 8, enabled bar [14] = type Memory, range 32, base 0xf6fda000, size 4096, enabled Oh, you do have the serial port on your notebook, usable remotely without serial cable. Your chipset seems to be AMT-capable, and you could use comms/amtterm from other machine to get a serial console. vgapci0@pci0:1:0:0: class=0x03 card=0x02501028 chip=0x065c10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'G96M [Quadro FX 770M]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xf500, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xe000, size 268435456, enabled bar [1c] = type Memory, range 64, base 0xf200, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled My current theory is that the nvidia aperture
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Thu, 21 Mar 2013 12:12:07 -0400 Shawn Webb latt...@gmail.com wrote: [snip lots of stuff] I appear to be experiencing the same issue. I've been following this thread. I have a coredump, but it's over 700mb in size. What would be the best way to get that to you guys? The revision I'm at is r248583 on amd64 (6GB RAM) with an NVIDIA Quadro FX 580. Relevant lines from `pciconf -lvb`: vgapci0@pci0:3:0:0: class=0x03 card=0x063a10de chip=0x065910de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'G96 [Quadro FX 580]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xf600, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xc000, size 536870912, enabled bar [1c] = type Memory, range 64, base 0xf400, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xdc80, size 128, enabled Looks like setting both vfs.unmapped_buf_allowed=0 and kern.bio_transient_maxcnt=512 worked for me. I'm now up and running smoothly. I wonder whether there isn't some dependency on the graphics chip being used. I'm running r248589 AMD64 and didn't have to touch a thing to get X to start. But I'm using an older, presumably less demanding graphics chip: vgapci0@pci0:1:0:0: class=0x03 card=0x19051462 chip=0x0a6510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GT218 [GeForce 210]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xfb00, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xc000, size 268435456, enabled bar [1c] = type Prefetchable Memory, range 64, base 0xde00, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xef00, size 128, enabled Above all, bar [14] is only half as large. -- Gary Jennejohn ___ 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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Thu, Mar 21, 2013 at 12:12:07PM -0400, Shawn Webb wrote: Looks like setting both vfs.unmapped_buf_allowed=0 and kern.bio_transient_maxcnt=512 worked for me. I'm now up and running smoothly. The vfs.unmapped_buf_allowed=0 setting turns off the unmapped support, and kern.bio_transient_maxcnt value does not matter then. pgpikdvEjyA5H.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Thu, Mar 21, 2013 at 07:14:26PM +0100, Gary Jennejohn wrote: I wonder whether there isn't some dependency on the graphics chip being used. I'm running r248589 AMD64 and didn't have to touch a thing to get X to start. But I'm using an older, presumably less demanding graphics chip: You use the amd64 kernel, which has ample KVA space. The problem is specific to i386. vgapci0@pci0:1:0:0: class=0x03 card=0x19051462 chip=0x0a6510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GT218 [GeForce 210]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xfb00, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xc000, size 268435456, enabled bar [1c] = type Prefetchable Memory, range 64, base 0xde00, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0xef00, size 128, enabled Above all, bar [14] is only half as large. pgpgPiH5R3fRP.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Thu, Mar 21, 2013 at 03:58:35PM +0200, Konstantin Belousov wrote:
...
Script started on Thu Mar 21 06:07:41 2013
g1-235(10.0-C)[1] uname -a
FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845
r248575M/248575: Thu Mar 21 05:35:06 PDT 2013
r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
g1-235(10.0-C)[2] sysctl vfs.unmapped_buf_allowed kern.bio_transient_maxcnt
kern.nbuf
vfs.unmapped_buf_allowed: 1
kern.bio_transient_maxcnt: 697
kern.nbuf: 7224
Could you, please, do some more measurements in the r248575M ?
Please show the kern.nbuf for vfs.unmapped_buf_allowed=0 case.
Also, from there, run kgdb /boot/kernel/kernel /dev/mem and do
p *buffer_map.
Reboot without applying any unmapped/transient tuning, run the kgdb
again, and do
p *buffer_map
p *bio_transient_map
Reboot with kern.bio_transient_maxcnt tunable set to 256 and again
print the buffer_map and bio_transient_map from the kgdb.
...
OK; sorry about the delay -- I needed to use the machinie for a while
(at work), and then I had a weekly staff meeting
Anyway... I've attached results of the above. For the first last, I
did each twice -- once using the nv driver, and once using the
nvidia driver. (The middle one only got the nv driver.)
So the files are:
kib_0_nv
kib_0_nvidia
kib_1_nv
kib_2_nv
kib_2_nvidia
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Script started on Thu Mar 21 10:39:14 2013
root@d129:~ # uname -a
FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845
r248575M/248575: Thu Mar 21 05:35:06 PDT 2013
r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
root@d129:~ # sysctl vfs.unmapped_buf_allowed
vfs.unmapped_buf_allowed: 0
root@d129:~ # k[Ksyst[Kctl kern.nbuf
kern.nbuf: 7224
root@d129:~ # kgdb /boot/kernel/kernel /dev/mem
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from
/boot/kernel/coretemp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/coretemp.ko
Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from
/boot/kernel/iwn5000fw.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/iwn5000fw.ko
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
/boot/kernel/tmpfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/tmpfs.ko
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/boot/kernel/fdescfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/fdescfs.ko
#0 sched_switch (td=0xc1312a70, newtd=0xcd98b900, flags=-1048441924)
at /usr/src/sys/kern/sched_ule.c:1954
1954cpuid = PCPU_GET(cpuid);
(kgdb) p *buffer_map
$1 = {header = {prev = 0xc19cf288, next = 0xc19cf288, left = 0x0, right = 0x0,
start = 3925868544, end = 4044226560, avail_ssize = 0, adj_free = 0,
max_free = 0, object = {vm_object = 0x0, sub_map = 0x0}, offset = 0,
eflags = 0, protection = 0 '\0', max_protection = 0 '\0',
inheritance = 0 '\0', read_ahead = 0 '\0', wired_count = 0, next_read = 0,
cred = 0x0}, lock = {lock_object = {lo_name = 0xc0fc6c80 vm map (user),
lo_flags = 36896768, lo_data = 0, lo_witness = 0xcd8022b0},
sx_lock = 1}, system_mtx = {lock_object = {
lo_name = 0xc0fc6c52 vm map (system), lo_flags = 21168128,
lo_data = 0, lo_witness = 0xcd802110}, mtx_lock = 4}, nentries = 1,
size = 84590592, timestamp = 5163, needs_wakeup = 0 '\0',
system_map = 1 '\001', flags = 0 '\0', root = 0xc19cf288, pmap = 0xc13279f8,
busy = 0}
Current language: auto; currently minimal
(kgdb) p *bio_transient_map
Error accessing memory address 0x0: Bad address.
(kgdb) root@d129:~ # ^Dexit
Script done on Thu Mar 21 10:40:35 2013
Script started on Thu Mar 21 10:43:15 2013
root@d129:~ # uname -a
FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #845
r248575M/248575: Thu Mar 21 05:35:06 PDT 2013
r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
root@d129:~ # sysctl vfs.unmapped_buf_allowed
vfs.unmapped_buf_allowed: 0
root@d129:~ # sysctl kern.nbuf
kern.nbuf: 7224
root@d129:~ # kgdp[Kb /boot/kernel/kernel /dev/mem
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
iI am @248554 on an AMD64 box with 8 gig of memory, and a 64 bit kernel. The video is on the motherboard and is a Radeon chipset. I also experienced the panic while starting XDM. I found Shawn's suggested remedy of etting both vfs.unmapped_buf_allowed=0 and kern.bio_transient_maxcnt=512 in /boot/loader.conf allows the box to boot, XDM to start and everything seems to be working. It's probably just my imagination, but it does seem slightly slower in starting applications. It seems that the common thing between my situation and Shawn's is the recent changes to drm.ko. -- Best regards, Derek Tattersall d...@mebtel.net dlt...@yahoo.com dtatt...@gmail.com ___ 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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
I've been having random panics since the VM changes. I'm stuck running r247527. If I try to install a newer kernel/world, I get random panics (I really should enable crashdumps). Not a big deal, but I'm mostly interested in epair fixes and bhyve enhancements. On Wed, Mar 20, 2013 at 12:00 PM, David Wolfskill da...@catwhisker.orgwrote: Yesterday, I built head ran it without incident (as has been the daily norm for some time now): FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #843 r248493M/248493: Tue Mar 19 05:57:09 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 Today, after updating to: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #844 r248550M/248551: Wed Mar 20 06:59:32 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 I find that booting to single-user mode is OK, and I can even start xdm -- as long as I did not kldload nvidia.ko first. (Indeed, I find that once loaded, the attempt to unload nvidia.ko appears to hang.) If (as has been my practice for the last several years) I loaded nvidia.ko (via /boot/loader.conf) before attempting to start xdm, when I do try starting xdm, the machine (my laptop -- no serial console) quietly initiates a reboot. Mounted file systems don't get unmounted first, so that tends to be mildly annoying -- and provides some evidence that the reboot isn't exactly being performed under ideal conditions (which, I admit, is not all that much of a surprise). Here's what happened during the svn update, so folks can see what files changed: Script started on Wed Mar 20 06:01:32 2013 svn update /usr/src Updating '/usr/src': U/usr/src/contrib/llvm/tools/clang/lib/Driver/Tools.cpp U/usr/src/share/man/man4/unix.4 U/usr/src/share/man/man4/iwn.4 U/usr/src/lib/libc/sys/recv.2 U/usr/src/lib/libc/sys/socket.2 U/usr/src/lib/libc/sys/socketpair.2 U/usr/src/sys/ia64/ia64/pmap.c U/usr/src/sys/mips/mips/pmap.c U/usr/src/sys/fs/nfsclient/nfs_clbio.c U/usr/src/sys/amd64/amd64/pmap.c U/usr/src/sys/sys/mount.h U/usr/src/sys/sys/systm.h U/usr/src/sys/sys/bio.h U/usr/src/sys/sys/socket.h U/usr/src/sys/sys/domain.h U/usr/src/sys/sys/buf.h U/usr/src/sys/powerpc/powerpc/pmap_dispatch.c U/usr/src/sys/powerpc/aim/mmu_oea64.c U/usr/src/sys/arm/arm/pmap-v6.c U/usr/src/sys/arm/arm/pmap.c U/usr/src/sys/vm/vm_kern.c U/usr/src/sys/vm/vm.h U/usr/src/sys/vm/vm_init.c U/usr/src/sys/vm/swap_pager.c U/usr/src/sys/vm/vnode_pager.c U/usr/src/sys/vm/swap_pager.h U/usr/src/sys/sparc64/sparc64/pmap.c U/usr/src/sys/net80211/ieee80211_freebsd.c U/usr/src/sys/nfsclient/nfs_bio.c U/usr/src/sys/geom/geom_io.c U/usr/src/sys/geom/geom_disk.c U/usr/src/sys/geom/geom_disk.h U/usr/src/sys/geom/part/g_part.c U/usr/src/sys/geom/geom.h U/usr/src/sys/geom/geom_vfs.c U/usr/src/sys/i386/i386/pmap.c U/usr/src/sys/i386/xen/pmap.c U/usr/src/sys/ufs/ufs/ufs_extern.h U/usr/src/sys/ufs/ffs/ffs_alloc.c U/usr/src/sys/ufs/ffs/ffs_balloc.c U/usr/src/sys/ufs/ffs/ffs_vfsops.c U/usr/src/sys/ufs/ffs/ffs_rawread.c U/usr/src/sys/ufs/ffs/ffs_vnops.c U/usr/src/sys/cam/cam_periph.c U/usr/src/sys/cam/cam_ccb.h U/usr/src/sys/cam/scsi/scsi_da.c U/usr/src/sys/cam/scsi/scsi_all.c U/usr/src/sys/cam/scsi/scsi_all.h U/usr/src/sys/cam/scsi/scsi_cd.c U/usr/src/sys/cam/ata/ata_da.c U/usr/src/sys/dev/mii/rgephyreg.h U/usr/src/sys/dev/mii/rgephy.c U/usr/src/sys/dev/usb/usbdevs U/usr/src/sys/dev/usb/serial/u3g.c U/usr/src/sys/dev/ath/if_ath_beacon.c U/usr/src/sys/dev/ath/if_ath_rx.c U/usr/src/sys/dev/ath/if_ath_tx.c U/usr/src/sys/dev/ath/if_ath.c U/usr/src/sys/dev/ath/if_athvar.h U/usr/src/sys/dev/ath/if_ath_rx_edma.c U/usr/src/sys/dev/ath/if_ath_tx_edma.c U/usr/src/sys/dev/siis/siis.c U/usr/src/sys/dev/fdt/fdt_common.c U/usr/src/sys/dev/ahci/ahci.c U/usr/src/sys/dev/md/md.c U/usr/src/sys/kern/kern_physio.c U/usr/src/sys/kern/subr_bus_dma.c U/usr/src/sys/kern/vfs_bio.c U/usr/src/sys/kern/subr_param.c U/usr/src/sys/kern/uipc_usrreq.c U/usr/src/sys/kern/uipc_socket.c U/usr/src/sys/kern/vfs_cluster.c U/usr/src/sys/kern/uipc_syscalls.c U/usr/src/sys/kern/vfs_aio.c U/usr/src/sbin/shutdown/shutdown.8 U/usr/src/sbin/ldconfig/ldconfig.c U/usr/src/sbin/ldconfig/ldconfig.8 Updated to revision 248551. I note that r248084 made some changes in src/sys/vm/ that broke x11/nvidia-driver a few days ago, and I hacked up a patch for that (which sbruno@ committed recently). Still, I had been running (without incident) using that patch And I freely admit that I'm far more of a hacker than a developer; I don't claim familiarity with the VM subsystem at all. But given that nvidia-driver
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 09:00:56AM -0700, David Wolfskill wrote: Yesterday, I built head ran it without incident (as has been the daily norm for some time now): FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #843 r248493M/248493: Tue Mar 19 05:57:09 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 Today, after updating to: FreeBSD g1-235.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #844 r248550M/248551: Wed Mar 20 06:59:32 PDT 2013 r...@g1-235.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 I find that booting to single-user mode is OK, and I can even start xdm -- as long as I did not kldload nvidia.ko first. (Indeed, I find that once loaded, the attempt to unload nvidia.ko appears to hang.) If (as has been my practice for the last several years) I loaded nvidia.ko (via /boot/loader.conf) before attempting to start xdm, when I do try starting xdm, the machine (my laptop -- no serial console) quietly initiates a reboot. Mounted file systems don't get unmounted first, so that tends to be mildly annoying -- and provides some evidence that the reboot isn't exactly being performed under ideal conditions (which, I admit, is not all that much of a surprise). Here's what happened during the svn update, so folks can see what files changed: Script started on Wed Mar 20 06:01:32 2013 svn update /usr/src Updating '/usr/src': U/usr/src/contrib/llvm/tools/clang/lib/Driver/Tools.cpp U/usr/src/share/man/man4/unix.4 U/usr/src/share/man/man4/iwn.4 U/usr/src/lib/libc/sys/recv.2 U/usr/src/lib/libc/sys/socket.2 U/usr/src/lib/libc/sys/socketpair.2 U/usr/src/sys/ia64/ia64/pmap.c U/usr/src/sys/mips/mips/pmap.c U/usr/src/sys/fs/nfsclient/nfs_clbio.c U/usr/src/sys/amd64/amd64/pmap.c U/usr/src/sys/sys/mount.h U/usr/src/sys/sys/systm.h U/usr/src/sys/sys/bio.h U/usr/src/sys/sys/socket.h U/usr/src/sys/sys/domain.h U/usr/src/sys/sys/buf.h U/usr/src/sys/powerpc/powerpc/pmap_dispatch.c U/usr/src/sys/powerpc/aim/mmu_oea64.c U/usr/src/sys/arm/arm/pmap-v6.c U/usr/src/sys/arm/arm/pmap.c U/usr/src/sys/vm/vm_kern.c U/usr/src/sys/vm/vm.h U/usr/src/sys/vm/vm_init.c U/usr/src/sys/vm/swap_pager.c U/usr/src/sys/vm/vnode_pager.c U/usr/src/sys/vm/swap_pager.h U/usr/src/sys/sparc64/sparc64/pmap.c U/usr/src/sys/net80211/ieee80211_freebsd.c U/usr/src/sys/nfsclient/nfs_bio.c U/usr/src/sys/geom/geom_io.c U/usr/src/sys/geom/geom_disk.c U/usr/src/sys/geom/geom_disk.h U/usr/src/sys/geom/part/g_part.c U/usr/src/sys/geom/geom.h U/usr/src/sys/geom/geom_vfs.c U/usr/src/sys/i386/i386/pmap.c U/usr/src/sys/i386/xen/pmap.c U/usr/src/sys/ufs/ufs/ufs_extern.h U/usr/src/sys/ufs/ffs/ffs_alloc.c U/usr/src/sys/ufs/ffs/ffs_balloc.c U/usr/src/sys/ufs/ffs/ffs_vfsops.c U/usr/src/sys/ufs/ffs/ffs_rawread.c U/usr/src/sys/ufs/ffs/ffs_vnops.c U/usr/src/sys/cam/cam_periph.c U/usr/src/sys/cam/cam_ccb.h U/usr/src/sys/cam/scsi/scsi_da.c U/usr/src/sys/cam/scsi/scsi_all.c U/usr/src/sys/cam/scsi/scsi_all.h U/usr/src/sys/cam/scsi/scsi_cd.c U/usr/src/sys/cam/ata/ata_da.c U/usr/src/sys/dev/mii/rgephyreg.h U/usr/src/sys/dev/mii/rgephy.c U/usr/src/sys/dev/usb/usbdevs U/usr/src/sys/dev/usb/serial/u3g.c U/usr/src/sys/dev/ath/if_ath_beacon.c U/usr/src/sys/dev/ath/if_ath_rx.c U/usr/src/sys/dev/ath/if_ath_tx.c U/usr/src/sys/dev/ath/if_ath.c U/usr/src/sys/dev/ath/if_athvar.h U/usr/src/sys/dev/ath/if_ath_rx_edma.c U/usr/src/sys/dev/ath/if_ath_tx_edma.c U/usr/src/sys/dev/siis/siis.c U/usr/src/sys/dev/fdt/fdt_common.c U/usr/src/sys/dev/ahci/ahci.c U/usr/src/sys/dev/md/md.c U/usr/src/sys/kern/kern_physio.c U/usr/src/sys/kern/subr_bus_dma.c U/usr/src/sys/kern/vfs_bio.c U/usr/src/sys/kern/subr_param.c U/usr/src/sys/kern/uipc_usrreq.c U/usr/src/sys/kern/uipc_socket.c U/usr/src/sys/kern/vfs_cluster.c U/usr/src/sys/kern/uipc_syscalls.c U/usr/src/sys/kern/vfs_aio.c U/usr/src/sbin/shutdown/shutdown.8 U/usr/src/sbin/ldconfig/ldconfig.c U/usr/src/sbin/ldconfig/ldconfig.8 Updated to revision 248551. I note that r248084 made some changes in src/sys/vm/ that broke x11/nvidia-driver a few days ago, and I hacked up a patch for that (which sbruno@ committed recently). Still, I had been running (without incident) using that patch And I freely admit that I'm far more of a hacker than a developer; I don't claim familiarity with the VM subsystem at all. But given that nvidia-driver is (evidently) somewhat sensitive with respect to the VM subsystem, I would be unsurprised to find that there might be some undesirable interactions between that and the changes kib@ recently committed to head (e.g., r248508). Unfortunately, I'm
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:13:41PM +0200, Konstantin Belousov wrote: ... I'm open to suggestions, and willing to hack and test (and report, of course). Did you rebuild the nvidia driver after the update ? Yes; src.conf includes the line: PORTS_MODULES=x11/nvidia-driver Do you have a core dump partition configured ? d129(10.0-C)[2] grep dump /etc/rc.conf dumpdev=AUTO Try to set vfs.unmapped_buf_allowed=0 at the loader prompt and see does it change anything. OK; will report shortly. Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpjwhRzQtsJE.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
on 20/03/2013 19:18 David Wolfskill said the following: Yes; src.conf includes the line: PORTS_MODULES=x11/nvidia-driver Have you double-checked that this actually works according to your intention? -- Andriy Gapon ___ 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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:13:41PM +0200, Konstantin Belousov wrote: ... Did you rebuild the nvidia driver after the update ? Do you have a core dump partition configured ? (I note that I have, in the past, captured crash dumps from head running on this machine with this configuration.) Try to set vfs.unmapped_buf_allowed=0 at the loader prompt and see does it change anything. OK; I tried this, then booted without attempting to start X in any way. I then logged in as root and verified that sysctl vfs.unmapped_buf_allowed reported 0. I then issued kldload nvidia.ko (and verified that it was loaded via kldstat). I then started xdm, and (as before), got an unclean reboot. (So: no difference in behavior as far as I can tell.) Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpWIRE86I7Qm.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 10:37:59AM -0700, David Wolfskill wrote: On Wed, Mar 20, 2013 at 07:13:41PM +0200, Konstantin Belousov wrote: ... Did you rebuild the nvidia driver after the update ? Do you have a core dump partition configured ? (I note that I have, in the past, captured crash dumps from head running on this machine with this configuration.) Try to set vfs.unmapped_buf_allowed=0 at the loader prompt and see does it change anything. OK; I tried this, then booted without attempting to start X in any way. I then logged in as root and verified that sysctl vfs.unmapped_buf_allowed reported 0. I then issued kldload nvidia.ko (and verified that it was loaded via kldstat). I then started xdm, and (as before), got an unclean reboot. (So: no difference in behavior as far as I can tell.) Ok. The best idea I have right now is to rebuild the nvidia.ko. Do you have a firewire port on the laptop ? pgp5s25xME8fB.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:24:30PM +0200, Andriy Gapon wrote: on 20/03/2013 19:18 David Wolfskill said the following: Yes; src.conf includes the line: PORTS_MODULES=x11/nvidia-driver Have you double-checked that this actually works according to your intention? ... Until I started specifying that, the attempt to load nvidia.ko would fail (under head), as the module resides in /boot/modules. Note that I have the (single) drive on this machine split into 4 bootable slices, each of which has its own root and /usr file system. (Slice 4 has the partitions that are common to all images -- one for swap; another for the /var FS; one for local SVN mirrors mounted on /repo; one for miscellaneous stuff, such as home directories, ports tree, and /usr/local, which I mount under /common. There's another FS called /bkp, but it's not actually used for much usually.) Since /usr/local is the same FS regardless of which slice is booted (thanks to symlinks), I build the ports under stable/9 (which is on slice 1). On the other hand, head is on slice 4. So building x11/nvidia-driver would populate /usr/local/lib and slice 1's /boot/modules, but would not populate any other slice's /boot/*. This is something I have been doing (in the general sense of multiple bootable slices) for over a decade, and have been doing it for x11/nvidia-driver (in particular) for a few years. I have been tracking stable/9 head daily for quite a while (years -- note the iteration number in the uname output), and after the smoke-test for stable/9, I update all installed ports that have been updated in the last 24 hrs. -- daily. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpNfitzF_Zdn.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:44:58PM +0200, Konstantin Belousov wrote: ... I then started xdm, and (as before), got an unclean reboot. (So: no difference in behavior as far as I can tell.) Ok. The best idea I have right now is to rebuild the nvidia.ko. Again? OK Do you have a firewire port on the laptop ? I do: ... none2@pci0:3:1:1: class=0x0c0010 card=0x02501028 chip=0x08321180 rev=0x04 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'R5C832 IEEE 1394 Controller' class = serial bus subclass = FireWire ... On the other hand, I'm less sure about any other machines around, or cables that would work. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpHHYnFoMhBh.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 07:44:58PM +0200, Konstantin Belousov wrote: ... Ok. The best idea I have right now is to rebuild the nvidia.ko. OK; I did this: After rebooting (without attempting to either load nvidia.ko or start X in any way), I issued: sudo portmaster x11/nvidia-driver which rebuilt reinstalled the driver. I then loaded nvidia.ko, and started xdm -- and as before, the machine performed a fairly hard reset. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp1JbuO3eP3Y.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 11:02:39AM -0700, David Wolfskill wrote: On Wed, Mar 20, 2013 at 07:44:58PM +0200, Konstantin Belousov wrote: ... Ok. The best idea I have right now is to rebuild the nvidia.ko. OK; I did this: After rebooting (without attempting to either load nvidia.ko or start X in any way), I issued: sudo portmaster x11/nvidia-driver which rebuilt reinstalled the driver. I then loaded nvidia.ko, and started xdm -- and as before, the machine performed a fairly hard reset. I looked at the nvidia sources to check that the driver does not use the interfaces which KBI was changed, and this is indeed the case, as expected. I must admit that I have no idea why buffer cache changes could affect nvidia driver, and with no input on the panic (I hope that it is panic, and not a reset) have no idea even to speculate. So firewire cable is probably the must. Note that I split that import of the work into the series of commits. The split was done to ease the reading of the chunks, and individual commits were not functionally tested. Still, you might try to do the bisect. pgpLIqF5CWk7K.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 10:08:57PM +0200, Konstantin Belousov wrote: ... I looked at the nvidia sources to check that the driver does not use the interfaces which KBI was changed, and this is indeed the case, as expected. OK; thank you for checking reporting. I must admit that I have no idea why buffer cache changes could affect nvidia driver, and with no input on the panic (I hope that it is panic, and not a reset) have no idea even to speculate. So firewire cable is probably the must. OK. Note that I split that import of the work into the series of commits. The split was done to ease the reading of the chunks, and individual commits were not functionally tested. Still, you might try to do the bisect. OK; I'll see what I can do. (It's a little awkward, as I use the laptop to access ... well, just about everything.) Thanks again! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp8Q45XfjkjA.pgp Description: PGP signature
Re: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
I would advise that you try the following: (1) On a machine which is not your laptop, build a CURRENT chroot (2) Follow the instructions at: http://www.freebsd.org/doc/handbook/network-pxe-nfs.html to NFS export the chroot and set up a TFTP server. (3) Set up your laptop to PXE boot using (2). This is one quick way you can test your laptop with CURRENT, without installing all the bits on the disk of your laptop. -- Craig On Wed, Mar 20, 2013 at 1:13 PM, David Wolfskill da...@catwhisker.orgwrote: On Wed, Mar 20, 2013 at 10:08:57PM +0200, Konstantin Belousov wrote: ... I looked at the nvidia sources to check that the driver does not use the interfaces which KBI was changed, and this is indeed the case, as expected. OK; thank you for checking reporting. I must admit that I have no idea why buffer cache changes could affect nvidia driver, and with no input on the panic (I hope that it is panic, and not a reset) have no idea even to speculate. So firewire cable is probably the must. OK. Note that I split that import of the work into the series of commits. The split was done to ease the reading of the chunks, and individual commits were not functionally tested. Still, you might try to do the bisect. OK; I'll see what I can do. (It's a little awkward, as I use the laptop to access ... well, just about everything.) Thanks again! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -- Craig Rodrigues rodr...@crodrigues.org ___ 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: Silent reboots in head @r248550 starting xdm with x11/nvidia-driver
On Wed, Mar 20, 2013 at 10:08:57PM +0200, Konstantin Belousov wrote: ... I looked at the nvidia sources to check that the driver does not use the interfaces which KBI was changed, and this is indeed the case, as expected. I must admit that I have no idea why buffer cache changes could affect nvidia driver, and with no input on the panic (I hope that it is panic, and not a reset) have no idea even to speculate. So firewire cable is probably the must. Note that I split that import of the work into the series of commits. The split was done to ease the reading of the chunks, and individual commits were not functionally tested. Still, you might try to do the bisect. I elected to go ahead and try the bisection; here are my results: r248493M/248493: OK r248550M/248551: resets on X startup with nvidia.ko r248521M/248521: resets on X startup with nvidia.ko r248507M/248507: OK r248508M/248508: resets on X startup with nvidia.ko r248493M/248493 was my last working point (built yesterday morning). r248550M/248551 was what failed for me this morning. r248521M/248521 was a convenient mid-point between the above two. r248507M/248507 was the next natural test-point. r248508M/248508 was a guess on my part -- I would normally have gone to r248514, but since I had previously noted that r248508 touched some things that nvidia-driver uses, I thought that test might be worthwhile. I am, however, mildly concerned that no one else appears to be reporting similar symptoms (though I have it on good authority that someone is about to test). Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpsMwuYLMMMc.pgp Description: PGP signature
