drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 18:38, Steven Newbury wrote: > On 13/04/12 17:17, Yinghai Lu wrote: Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. >>> Just hit the same oops on the rc1+for-pci-res-alloc kernel I >>> tried earlier so it's not definitely something new in the >>> btrfs code. Seems like it's a 64/32bit pointer issue?? > >> for-pci-res-alloc include > >> for-pci-hostbridge-cleanup for-pci-busn-alloc >> for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 >> patches. > >> maybe there is some problem with for-pci-for-each-res-addon. > >> just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please >> check if the problem still there. > > Still Oopses. I'm going to try linus/master. Perhaps it's a > filesystem corruption triggering it? I do find it a little > suspicious that it occurs in "btrfs:find_workspace" though, code > which deals with memory allocations... Damn. It still oopses with my linus tracking branch! I'm going to restore from backup and see if it still happens. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IbJ8ACgkQGcb56gMuC60bVQCfbIQEd+kpJBrXdeiz/sfJOCC2 f9oAnA4DYSOD1ApvbMl937dxG2i6SYDv =uZ3A -END PGP SIGNATURE-
drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 17:17, Yinghai Lu wrote: >>> Looks like either a btrfs regression or bad interaction with >>> for-pci-res-alloc. Oops attached. >> Just hit the same oops on the rc1+for-pci-res-alloc kernel I >> tried earlier so it's not definitely something new in the btrfs >> code. Seems like it's a 64/32bit pointer issue?? > > for-pci-res-alloc include > > for-pci-hostbridge-cleanup for-pci-busn-alloc > for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 > patches. > > maybe there is some problem with for-pci-for-each-res-addon. > > just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please > check if the problem still there. > Still Oopses. I'm going to try linus/master. Perhaps it's a filesystem corruption triggering it? I do find it a little suspicious that it occurs in "btrfs:find_workspace" though, code which deals with memory allocations... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IZHsACgkQGcb56gMuC62WhQCgkVBccCKKLqjL1S7f+4wzXnT7 DbsAn2wQNiQLGo95Q3W9bWu6n5Q3xqr8 =Rtn+ -END PGP SIGNATURE-
btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 17:17, Yinghai Lu wrote: >>> Looks like either a btrfs regression or bad interaction with >>> for-pci-res-alloc. Oops attached. >> Just hit the same oops on the rc1+for-pci-res-alloc kernel I >> tried earlier so it's not definitely something new in the btrfs >> code. Seems like it's a 64/32bit pointer issue?? > > for-pci-res-alloc include > > for-pci-hostbridge-cleanup for-pci-busn-alloc > for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 > patches. > > maybe there is some problem with for-pci-for-each-res-addon. > > just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please > check if the problem still there. > > Thanks > > Yinghai BTW, previously, I was based on your for-pci-busn-alloc branch, didn't see any problems there. Recompiling now with a clean merge of updated for-pci-res-alloc on top of my linus tracking branch... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IXpEACgkQGcb56gMuC63ubwCgkyr2d4Xp/4OpLo4ehIYrabtO /SgAoKDaYPOxX9qRznUjUIoYAmPF3thA =s+mx -END PGP SIGNATURE-
drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 16:23, Steven Newbury wrote: > On 13/04/12 15:19, Steven Newbury wrote: >> On 13/04/12 15:13, Daniel Vetter wrote: >>> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury >>> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 14:52, Steven Newbury wrote: > On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 13/04/12 13:49, Steven Newbury wrote: >>> On 13/04/12 12:58, Steven Newbury wrote: >>> > It's not stable, crashes soon after GMA comes up. > (Could be unrelated breakage in linus/master? > Probably not but I will verify.) I noticed the > high allocations are occuring from the top of > 64-bit address-space, whilst /proc/cpuinfo shows > only 48 bits of virtual addressing. Could that be > why..? To reply to myself again, I should have said crashes shortly after Xorg initialises using the intel driver, in both cases! I'm building a kernel now without the patch set to see if it's unrelated. If it still dies I'll try applying your patch set to a branch without the changes from linus/master... (should have done that anyway...) >>> >>> Okay, I instead created a branch from an older 3.4-rc1+ >>> kernel tree, running it now, and it seems to be >>> stable. Something perhaps in the newer tree not playing >>> nicely. I'll see if I can bisect it, or at least base >>> of rc2 if that works... (I'm a little wary of crashing >>> the system too much and losing my btrfs filesystem...) >> rc2 is fine as well. Not sure what happened there, I >> need to be more careful about keeping a clean tree to >> work from. > I'm pretty sure the crash was a from a drm-next regression. > I'll try bisecting it Sorry, posted too soon! Almost as I clicked on send it froze again (using rc2 + for-pci-res-alloc ). I had problems with the earlier patches re. X/i915 stability. Strange. I'll see if I can track it down. > >>> Please upgrade to the latest version of Linus' upstream git. A >>> few fixes for regressions in drm/i915 just landed there for >>> -rc3. -Daniel > >> Okay. I'll try clean latest linus + for-pci-res-alloc. Will >> report back. > > Looks like either a btrfs regression or bad interaction with > for-pci-res-alloc. Oops attached. Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried earlier so it's not definitely something new in the btrfs code. Seems like it's a 64/32bit pointer issue?? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ISyEACgkQGcb56gMuC63uRwCcCLm8yx1YVnTBSvT/9jx/IqEb WcYAoJh5iceqZvDDGdJHV88YwEyEnM32 =jfup -END PGP SIGNATURE-
drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 15:19, Steven Newbury wrote: > On 13/04/12 15:13, Daniel Vetter wrote: >> On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>> >>> On 13/04/12 14:52, Steven Newbury wrote: On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury wrote: > -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > On 13/04/12 13:49, Steven Newbury wrote: >> On 13/04/12 12:58, Steven Newbury wrote: >> It's not stable, crashes soon after GMA comes up. (Could be unrelated breakage in linus/master? Probably not but I will verify.) I noticed the high allocations are occuring from the top of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of virtual addressing. Could that be why..? >>> To reply to myself again, I should have said crashes >>> shortly after Xorg initialises using the intel driver, >>> in both cases! I'm building a kernel now without the >>> patch set to see if it's unrelated. If it still dies >>> I'll try applying your patch set to a branch without >>> the changes from linus/master... (should have done that >>> anyway...) >> >> Okay, I instead created a branch from an older 3.4-rc1+ >> kernel tree, running it now, and it seems to be stable. >> Something perhaps in the newer tree not playing nicely. >> I'll see if I can bisect it, or at least base of rc2 if >> that works... (I'm a little wary of crashing the system >> too much and losing my btrfs filesystem...) > rc2 is fine as well. Not sure what happened there, I > need to be more careful about keeping a clean tree to work > from. I'm pretty sure the crash was a from a drm-next regression. I'll try bisecting it >>> Sorry, posted too soon! Almost as I clicked on send it froze >>> again (using rc2 + for-pci-res-alloc ). I had problems with >>> the earlier patches re. X/i915 stability. Strange. I'll see >>> if I can track it down. > >> Please upgrade to the latest version of Linus' upstream git. A >> few fixes for regressions in drm/i915 just landed there for -rc3. >> -Daniel > > Okay. I'll try clean latest linus + for-pci-res-alloc. Will > report back. > Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IROAACgkQGcb56gMuC63hFQCguhdhV6AUoNKHnasgD0zjqJXt AwkAoKh8Rdrj3PqzuYUXpUkvyw3TujZV =XiAW -END PGP SIGNATURE- -- next part -- Apr 13 15:10:02 infinity kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Apr 13 15:10:02 infinity kernel: IP: [] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: PGD 7bfb2067 PUD d8978067 PMD 0 Apr 13 15:10:02 infinity kernel: Oops: [#1] SMP Apr 13 15:10:02 infinity kernel: CPU 1 Apr 13 15:10:02 infinity kernel: Modules linked in: cryptd aes_x86_64 aes_generic fuse fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font tileblit joydev arc4 dell_wmi sparse_keymap 8250_pnp dell_laptop dcdbas btusb bluetooth snd_hda_codec_idt crc16 microcode psmouse pcspkr iwl4965 iwlegacy snd_hda_intel mac80211 snd_hda_codec snd_hwdep tg3 snd_pcm cfg80211 snd_page_alloc snd_timer snd soundcore wmi 8250 serial_core evdev smsc47m192 hwmon_vid tpm_tis tpm tpm_bios rfkill loop nfs nfs_acl auth_rpcgss fscache lockd sunrpc phc_intel mperf coretemp hwmon autofs4 usb_storage usb_libusual uas btrfs zlib_deflate sd_mod pata_acpi ahci libahci ata_piix libata scsi_mod ehci_hcd uhci_hcd usbcore usb_common i915 video intel_agp intel_gtt cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight drm_kms_helper drm agpgart Apr 13 15:10:02 infinity kernel: Apr 13 15:10:02 infinity kernel: Pid: 2591, comm: btrfs-endio-2 Not tainted 3.4.0-rc2-wl-00669-g502ad46 #110 Dell Inc. Latitude D830 /0HN341 Apr 13 15:10:02 infinity kernel: RIP: 0010:[] [] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: RSP: 0018:880078e7fcc0 EFLAGS: 00010207 Apr 13 15:10:02 infinity kernel: RAX: RBX: 0003 RCX: 88007bde9000 Apr 13 15:10:02 infinity kernel: RDX: a029d500 RSI: dead00200200 RDI: a029d4f6 Apr 13 15:10:02 infinity kernel: RBP: 880078e7fd50 R08: 0008 R09: 4000 Apr 13 15:10:02 infinity kernel: R10: 0200 R11: 0200 R12: 880078e7fcf8 Apr 13 15:10:02 infinity kernel: R13: a029d504 R14: a029d4f6 R15: 880078e7fd10 Apr 13 15:10:02 infinity kernel: FS: () GS:88011fd0() knlGS: Apr 13 15:10:02 infinity kernel: CS: 0010 DS: ES: CR0:
drm-next i915 regression? ( was: Re: PCI resources above 4GB)
On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 13/04/12 14:52, Steven Newbury wrote: > > On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury > > wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >> > >> On 13/04/12 13:49, Steven Newbury wrote: > >>> On 13/04/12 12:58, Steven Newbury wrote: > >>> > > It's not stable, crashes soon after GMA comes up. (Could be > > unrelated breakage in linus/master? Probably not but I > > will verify.) I noticed the high allocations are occuring > > from the top of 64-bit address-space, whilst /proc/cpuinfo > > shows only 48 bits of virtual addressing. Could that be > > why..? > To reply to myself again, I should have said crashes shortly > after Xorg initialises using the intel driver, in both > cases! I'm building a kernel now without the patch set to see > if it's unrelated. If it still dies I'll try applying your > patch set to a branch without the changes from > linus/master... (should have done that anyway...) > >>> > >>> Okay, I instead created a branch from an older 3.4-rc1+ kernel > >>> tree, running it now, and it seems to be stable. Something > >>> perhaps in the newer tree not playing nicely. I'll see if I > >>> can bisect it, or at least base of rc2 if that works... (I'm a > >>> little wary of crashing the system too much and losing my btrfs > >>> filesystem...) > >> rc2 is fine as well. Not sure what happened there, I need to be > >> more careful about keeping a clean tree to work from. > > I'm pretty sure the crash was a from a drm-next regression. I'll > > try bisecting it > Sorry, posted too soon! Almost as I clicked on send it froze again > (using rc2 + for-pci-res-alloc ). I had problems with the earlier > patches re. X/i915 stability. Strange. I'll see if I can track it down. Please upgrade to the latest version of Linus' upstream git. A few fixes for regressions in drm/i915 just landed there for -rc3. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 15:13, Daniel Vetter wrote: > On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 13/04/12 14:52, Steven Newbury wrote: >>> On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury >>> wrote: >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 13:49, Steven Newbury wrote: > On 13/04/12 12:58, Steven Newbury wrote: > >>> It's not stable, crashes soon after GMA comes up. >>> (Could be unrelated breakage in linus/master? Probably >>> not but I will verify.) I noticed the high >>> allocations are occuring from the top of 64-bit >>> address-space, whilst /proc/cpuinfo shows only 48 bits >>> of virtual addressing. Could that be why..? >> To reply to myself again, I should have said crashes >> shortly after Xorg initialises using the intel driver, in >> both cases! I'm building a kernel now without the patch >> set to see if it's unrelated. If it still dies I'll try >> applying your patch set to a branch without the changes >> from linus/master... (should have done that anyway...) > > Okay, I instead created a branch from an older 3.4-rc1+ > kernel tree, running it now, and it seems to be stable. > Something perhaps in the newer tree not playing nicely. > I'll see if I can bisect it, or at least base of rc2 if > that works... (I'm a little wary of crashing the system too > much and losing my btrfs filesystem...) rc2 is fine as well. Not sure what happened there, I need to be more careful about keeping a clean tree to work from. >>> I'm pretty sure the crash was a from a drm-next regression. >>> I'll try bisecting it >> Sorry, posted too soon! Almost as I clicked on send it froze >> again (using rc2 + for-pci-res-alloc ). I had problems with the >> earlier patches re. X/i915 stability. Strange. I'll see if I >> can track it down. > > Please upgrade to the latest version of Linus' upstream git. A few > fixes for regressions in drm/i915 just landed there for -rc3. > -Daniel Okay. I'll try clean latest linus + for-pci-res-alloc. Will report back. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+INg4ACgkQGcb56gMuC60pJgCfS/g2k3mzIqU34de/Y4wTvfCP +hwAmQEEdgQ/y0QvDbPffNZ6izqs2Dce =EGwB -END PGP SIGNATURE-
drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 14:52, Steven Newbury wrote: > On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 13/04/12 13:49, Steven Newbury wrote: >>> On 13/04/12 12:58, Steven Newbury wrote: >>> > It's not stable, crashes soon after GMA comes up. (Could be > unrelated breakage in linus/master? Probably not but I > will verify.) I noticed the high allocations are occuring > from the top of 64-bit address-space, whilst /proc/cpuinfo > shows only 48 bits of virtual addressing. Could that be > why..? To reply to myself again, I should have said crashes shortly after Xorg initialises using the intel driver, in both cases! I'm building a kernel now without the patch set to see if it's unrelated. If it still dies I'll try applying your patch set to a branch without the changes from linus/master... (should have done that anyway...) >>> >>> Okay, I instead created a branch from an older 3.4-rc1+ kernel >>> tree, running it now, and it seems to be stable. Something >>> perhaps in the newer tree not playing nicely. I'll see if I >>> can bisect it, or at least base of rc2 if that works... (I'm a >>> little wary of crashing the system too much and losing my btrfs >>> filesystem...) >> rc2 is fine as well. Not sure what happened there, I need to be >> more careful about keeping a clean tree to work from. > I'm pretty sure the crash was a from a drm-next regression. I'll > try bisecting it Sorry, posted too soon! Almost as I clicked on send it froze again (using rc2 + for-pci-res-alloc ). I had problems with the earlier patches re. X/i915 stability. Strange. I'll see if I can track it down. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IM2QACgkQGcb56gMuC63IqACgpvN/bOqt/DWR45Kq00D4T2m0 tGoAn0cSN1eNxiHSF1eIRJgkGT/VmJy4 =/wQF -END PGP SIGNATURE-
drm-next i915 regression? ( was: Re: PCI resources above 4GB)
On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 13/04/12 13:49, Steven Newbury wrote: > > On 13/04/12 12:58, Steven Newbury wrote: > > > > > > It's not stable, crashes soon after GMA comes up. (Could be > > > > unrelated breakage in linus/master? Probably not but I will > > > > verify.)? I noticed the high allocations are occuring from the > > > > top of 64-bit address-space, whilst /proc/cpuinfo shows only > > > > 48 bits of virtual addressing.? Could that be why..? > > > To reply to myself again, I should have said crashes shortly > > > after Xorg initialises using the intel driver, in both cases! > > > I'm building a kernel now without the patch set to see if it's > > > unrelated.? If it still dies I'll try applying your patch set to > > > a branch without the changes from linus/master... (should have > > > done that anyway...) > > > > Okay, I instead created a branch from an older 3.4-rc1+ kernel > > tree, running it now, and it seems to be stable.? Something perhaps > > in the newer tree not playing nicely.? I'll see if I can bisect it, > > or at least base of rc2 if that works... (I'm a little wary of > > crashing the system too much and losing my btrfs filesystem...) > rc2 is fine as well.? Not sure what happened there, I need to be more > careful about keeping a clean tree to work from. I'm pretty sure the crash was a from a drm-next regression. I'll try bisecting it
drm-next i915 regression? ( was: Re: PCI resources above 4GB)
>> Looks like either a btrfs regression or bad interaction with >> for-pci-res-alloc. ?Oops attached. > Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried > earlier so it's not definitely something new in the btrfs code. ?Seems > like it's a 64/32bit pointer issue?? for-pci-res-alloc include for-pci-hostbridge-cleanup for-pci-busn-alloc for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 patches. maybe there is some problem with for-pci-for-each-res-addon. just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please check if the problem still there. Thanks Yinghai
drm-next i915 regression? ( was: Re: PCI resources above 4GB)
On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury st...@snewbury.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 13:49, Steven Newbury wrote: On 13/04/12 12:58, Steven Newbury wrote: It's not stable, crashes soon after GMA comes up. (Could be unrelated breakage in linus/master? Probably not but I will verify.) I noticed the high allocations are occuring from the top of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of virtual addressing. Could that be why..? To reply to myself again, I should have said crashes shortly after Xorg initialises using the intel driver, in both cases! I'm building a kernel now without the patch set to see if it's unrelated. If it still dies I'll try applying your patch set to a branch without the changes from linus/master... (should have done that anyway...) Okay, I instead created a branch from an older 3.4-rc1+ kernel tree, running it now, and it seems to be stable. Something perhaps in the newer tree not playing nicely. I'll see if I can bisect it, or at least base of rc2 if that works... (I'm a little wary of crashing the system too much and losing my btrfs filesystem...) rc2 is fine as well. Not sure what happened there, I need to be more careful about keeping a clean tree to work from. I'm pretty sure the crash was a from a drm-next regression. I'll try bisecting it ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 15:13, Daniel Vetter wrote: On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 14:52, Steven Newbury wrote: On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury st...@snewbury.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 13:49, Steven Newbury wrote: On 13/04/12 12:58, Steven Newbury wrote: It's not stable, crashes soon after GMA comes up. (Could be unrelated breakage in linus/master? Probably not but I will verify.) I noticed the high allocations are occuring from the top of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of virtual addressing. Could that be why..? To reply to myself again, I should have said crashes shortly after Xorg initialises using the intel driver, in both cases! I'm building a kernel now without the patch set to see if it's unrelated. If it still dies I'll try applying your patch set to a branch without the changes from linus/master... (should have done that anyway...) Okay, I instead created a branch from an older 3.4-rc1+ kernel tree, running it now, and it seems to be stable. Something perhaps in the newer tree not playing nicely. I'll see if I can bisect it, or at least base of rc2 if that works... (I'm a little wary of crashing the system too much and losing my btrfs filesystem...) rc2 is fine as well. Not sure what happened there, I need to be more careful about keeping a clean tree to work from. I'm pretty sure the crash was a from a drm-next regression. I'll try bisecting it Sorry, posted too soon! Almost as I clicked on send it froze again (using rc2 + for-pci-res-alloc ). I had problems with the earlier patches re. X/i915 stability. Strange. I'll see if I can track it down. Please upgrade to the latest version of Linus' upstream git. A few fixes for regressions in drm/i915 just landed there for -rc3. -Daniel Okay. I'll try clean latest linus + for-pci-res-alloc. Will report back. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+INg4ACgkQGcb56gMuC60pJgCfS/g2k3mzIqU34de/Y4wTvfCP +hwAmQEEdgQ/y0QvDbPffNZ6izqs2Dce =EGwB -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 15:19, Steven Newbury wrote: On 13/04/12 15:13, Daniel Vetter wrote: On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 14:52, Steven Newbury wrote: On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury st...@snewbury.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 13:49, Steven Newbury wrote: On 13/04/12 12:58, Steven Newbury wrote: It's not stable, crashes soon after GMA comes up. (Could be unrelated breakage in linus/master? Probably not but I will verify.) I noticed the high allocations are occuring from the top of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of virtual addressing. Could that be why..? To reply to myself again, I should have said crashes shortly after Xorg initialises using the intel driver, in both cases! I'm building a kernel now without the patch set to see if it's unrelated. If it still dies I'll try applying your patch set to a branch without the changes from linus/master... (should have done that anyway...) Okay, I instead created a branch from an older 3.4-rc1+ kernel tree, running it now, and it seems to be stable. Something perhaps in the newer tree not playing nicely. I'll see if I can bisect it, or at least base of rc2 if that works... (I'm a little wary of crashing the system too much and losing my btrfs filesystem...) rc2 is fine as well. Not sure what happened there, I need to be more careful about keeping a clean tree to work from. I'm pretty sure the crash was a from a drm-next regression. I'll try bisecting it Sorry, posted too soon! Almost as I clicked on send it froze again (using rc2 + for-pci-res-alloc ). I had problems with the earlier patches re. X/i915 stability. Strange. I'll see if I can track it down. Please upgrade to the latest version of Linus' upstream git. A few fixes for regressions in drm/i915 just landed there for -rc3. -Daniel Okay. I'll try clean latest linus + for-pci-res-alloc. Will report back. Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IROAACgkQGcb56gMuC63hFQCguhdhV6AUoNKHnasgD0zjqJXt AwkAoKh8Rdrj3PqzuYUXpUkvyw3TujZV =XiAW -END PGP SIGNATURE- Apr 13 15:10:02 infinity kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Apr 13 15:10:02 infinity kernel: IP: [a02778d0] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: PGD 7bfb2067 PUD d8978067 PMD 0 Apr 13 15:10:02 infinity kernel: Oops: [#1] SMP Apr 13 15:10:02 infinity kernel: CPU 1 Apr 13 15:10:02 infinity kernel: Modules linked in: cryptd aes_x86_64 aes_generic fuse fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font tileblit joydev arc4 dell_wmi sparse_keymap 8250_pnp dell_laptop dcdbas btusb bluetooth snd_hda_codec_idt crc16 microcode psmouse pcspkr iwl4965 iwlegacy snd_hda_intel mac80211 snd_hda_codec snd_hwdep tg3 snd_pcm cfg80211 snd_page_alloc snd_timer snd soundcore wmi 8250 serial_core evdev smsc47m192 hwmon_vid tpm_tis tpm tpm_bios rfkill loop nfs nfs_acl auth_rpcgss fscache lockd sunrpc phc_intel mperf coretemp hwmon autofs4 usb_storage usb_libusual uas btrfs zlib_deflate sd_mod pata_acpi ahci libahci ata_piix libata scsi_mod ehci_hcd uhci_hcd usbcore usb_common i915 video intel_agp intel_gtt cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight drm_kms_helper drm agpgart Apr 13 15:10:02 infinity kernel: Apr 13 15:10:02 infinity kernel: Pid: 2591, comm: btrfs-endio-2 Not tainted 3.4.0-rc2-wl-00669-g502ad46 #110 Dell Inc. Latitude D830 /0HN341 Apr 13 15:10:02 infinity kernel: RIP: 0010:[a02778d0] [a02778d0] find_workspace+0x92/0x190 [btrfs] Apr 13 15:10:02 infinity kernel: RSP: 0018:880078e7fcc0 EFLAGS: 00010207 Apr 13 15:10:02 infinity kernel: RAX: RBX: 0003 RCX: 88007bde9000 Apr 13 15:10:02 infinity kernel: RDX: a029d500 RSI: dead00200200 RDI: a029d4f6 Apr 13 15:10:02 infinity kernel: RBP: 880078e7fd50 R08: 0008 R09: 4000 Apr 13 15:10:02 infinity kernel: R10: 0200 R11: 0200 R12: 880078e7fcf8 Apr 13 15:10:02 infinity kernel: R13: a029d504 R14: a029d4f6 R15: 880078e7fd10 Apr 13 15:10:02 infinity kernel: FS: () GS:88011fd0() knlGS: Apr 13 15:10:02 infinity kernel: CS: 0010 DS: ES: CR0: 8005003b Apr 13 15:10:02 infinity kernel: CR2: CR3: 7bfe6000 CR4: 07e0 Apr 13 15:10:02 infinity kernel: DR0: DR1: DR2:
Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 16:23, Steven Newbury wrote: On 13/04/12 15:19, Steven Newbury wrote: On 13/04/12 15:13, Daniel Vetter wrote: On Fri, Apr 13, 2012 at 03:08:36PM +0100, Steven Newbury wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 14:52, Steven Newbury wrote: On Fri, 13 Apr 2012, 14:26:19 BST, Steven Newbury st...@snewbury.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 13:49, Steven Newbury wrote: On 13/04/12 12:58, Steven Newbury wrote: It's not stable, crashes soon after GMA comes up. (Could be unrelated breakage in linus/master? Probably not but I will verify.) I noticed the high allocations are occuring from the top of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of virtual addressing. Could that be why..? To reply to myself again, I should have said crashes shortly after Xorg initialises using the intel driver, in both cases! I'm building a kernel now without the patch set to see if it's unrelated. If it still dies I'll try applying your patch set to a branch without the changes from linus/master... (should have done that anyway...) Okay, I instead created a branch from an older 3.4-rc1+ kernel tree, running it now, and it seems to be stable. Something perhaps in the newer tree not playing nicely. I'll see if I can bisect it, or at least base of rc2 if that works... (I'm a little wary of crashing the system too much and losing my btrfs filesystem...) rc2 is fine as well. Not sure what happened there, I need to be more careful about keeping a clean tree to work from. I'm pretty sure the crash was a from a drm-next regression. I'll try bisecting it Sorry, posted too soon! Almost as I clicked on send it froze again (using rc2 + for-pci-res-alloc ). I had problems with the earlier patches re. X/i915 stability. Strange. I'll see if I can track it down. Please upgrade to the latest version of Linus' upstream git. A few fixes for regressions in drm/i915 just landed there for -rc3. -Daniel Okay. I'll try clean latest linus + for-pci-res-alloc. Will report back. Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried earlier so it's not definitely something new in the btrfs code. Seems like it's a 64/32bit pointer issue?? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ISyEACgkQGcb56gMuC63uRwCcCLm8yx1YVnTBSvT/9jx/IqEb WcYAoJh5iceqZvDDGdJHV88YwEyEnM32 =jfup -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)
Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried earlier so it's not definitely something new in the btrfs code. Seems like it's a 64/32bit pointer issue?? for-pci-res-alloc include for-pci-hostbridge-cleanup for-pci-busn-alloc for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 patches. maybe there is some problem with for-pci-for-each-res-addon. just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please check if the problem still there. Thanks Yinghai ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
btrfs oops [was Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 17:17, Yinghai Lu wrote: Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried earlier so it's not definitely something new in the btrfs code. Seems like it's a 64/32bit pointer issue?? for-pci-res-alloc include for-pci-hostbridge-cleanup for-pci-busn-alloc for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 patches. maybe there is some problem with for-pci-for-each-res-addon. just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please check if the problem still there. Thanks Yinghai BTW, previously, I was based on your for-pci-busn-alloc branch, didn't see any problems there. Recompiling now with a clean merge of updated for-pci-res-alloc on top of my linus tracking branch... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IXpEACgkQGcb56gMuC63ubwCgkyr2d4Xp/4OpLo4ehIYrabtO /SgAoKDaYPOxX9qRznUjUIoYAmPF3thA =s+mx -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 17:17, Yinghai Lu wrote: Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried earlier so it's not definitely something new in the btrfs code. Seems like it's a 64/32bit pointer issue?? for-pci-res-alloc include for-pci-hostbridge-cleanup for-pci-busn-alloc for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 patches. maybe there is some problem with for-pci-for-each-res-addon. just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please check if the problem still there. Still Oopses. I'm going to try linus/master. Perhaps it's a filesystem corruption triggering it? I do find it a little suspicious that it occurs in btrfs:find_workspace though, code which deals with memory allocations... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IZHsACgkQGcb56gMuC62WhQCgkVBccCKKLqjL1S7f+4wzXnT7 DbsAn2wQNiQLGo95Q3W9bWu6n5Q3xqr8 =Rtn+ -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/04/12 18:38, Steven Newbury wrote: On 13/04/12 17:17, Yinghai Lu wrote: Looks like either a btrfs regression or bad interaction with for-pci-res-alloc. Oops attached. Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried earlier so it's not definitely something new in the btrfs code. Seems like it's a 64/32bit pointer issue?? for-pci-res-alloc include for-pci-hostbridge-cleanup for-pci-busn-alloc for-pci-root-bus-hotplug for-pci-for-each-res-addon at plus 7 patches. maybe there is some problem with for-pci-for-each-res-addon. just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please check if the problem still there. Still Oopses. I'm going to try linus/master. Perhaps it's a filesystem corruption triggering it? I do find it a little suspicious that it occurs in btrfs:find_workspace though, code which deals with memory allocations... Damn. It still oopses with my linus tracking branch! I'm going to restore from backup and see if it still happens. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IbJ8ACgkQGcb56gMuC60bVQCfbIQEd+kpJBrXdeiz/sfJOCC2 f9oAnA4DYSOD1ApvbMl937dxG2i6SYDv =uZ3A -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
