Bug 27574 - BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
Summary: BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
Status: RESOLVED DUPLICATE of bug 26521
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: 7.5 (2009.10)
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-10 04:22 UTC by Alexander
Modified: 2010-06-28 14:13 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
kernel.log (262.08 KB, application/octet-stream)
2010-04-10 04:22 UTC, Alexander
no flags Details
2.6.34-rc4 kernel log (319.72 KB, text/plain)
2010-04-16 01:07 UTC, Alexander
no flags Details

Description Alexander 2010-04-10 04:22:28 UTC
Created attachment 34870 [details]
kernel.log

I caught it after resume from s2ram
Comment 1 Xavier 2010-04-14 02:49:02 UTC
Just for the record, Alex reported this bug to kernel bugzilla in the same time :
https://bugzilla.kernel.org/attachment.cgi?id=25936

And also 2 months ago already on FDO, but mixed with other issues about s2ram and s2disk :
http://bugs.freedesktop.org/show_bug.cgi?id=26521
Another user (Michal) caught the same trace there too :
http://bugs.freedesktop.org/attachment.cgi?id=34299
Comment 2 Alexander 2010-04-16 01:06:33 UTC
I caught it with 2.6.34-rc4, and looks like it happens every third time after suspend to ram.
Comment 3 Alexander 2010-04-16 01:07:04 UTC
Created attachment 35081 [details]
2.6.34-rc4 kernel log
Comment 4 Alexander 2010-04-23 09:31:53 UTC
Forgot to mention, may be that can help, I have nouveau built in kernel not as module.
Comment 5 Alexander 2010-04-30 02:53:57 UTC
I reproduced it on 2.6.34-rc5 and 2.6.34-rc6, seems like nobody from nouveau team isn't interested in fixing this bug
Comment 6 Maarten Maathuis 2010-04-30 03:57:32 UTC
Bugs can be non trivial to fix if you never hit them yourself. In this case it would be nice to know what value "mem->mem_type" has in ttm_pci_offset. So if you feel like poking around, that's where i would start. 0 is system, 1 is gart, 2 is vram, other is bad.
Comment 7 Alexander 2010-04-30 04:09:46 UTC
So if can give some instructions I can help you with investigation
Comment 8 Maarten Maathuis 2010-04-30 04:18:08 UTC
Adding this to the beginning of the ttm_bo_pci_offset function should print the value every time, you may have to revert it afterwards because of flooded logs.

printk(KERN_INFO TTM_PFX "mem->mem_type %d\n", mem->mem_type);
Comment 9 Alexander 2010-05-02 14:50:54 UTC
I still can't reproduce exactly this bug with proposed debugging but I have following error or something like this after which system or just X completely freeze and doesn't respond


May  3 00:37:40 loki kernel: [47292.941614] video LNXVIDEO:01: Restoring backlight state
May  3 00:37:40 loki kernel: [47293.171676] [TTM] mem->mem_type 2
May  3 00:37:40 loki kernel: [47293.185220] [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2
May  3 00:37:40 loki kernel: [47293.186640] [drm] nouveau 0000:01:00.0: PFIFO_CACHE_ERROR - Ch 2/0 Mthd 0x0000 Data 0x0f000000
May  3 00:37:40 loki kernel: [47293.186651] [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2

it happens on resume from ram also
Comment 10 Marcin Slusarz 2010-06-28 14:13:18 UTC

*** This bug has been marked as a duplicate of bug 26521 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.