| Summary: | [2.6.25 regression] uvesafb/vesafb freeze when switching back to console | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Oliver R <oliii2007> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | VERIFIED UPSTREAM | ||
| Severity: | normal | CC: | covici, gatraun, ok, spock |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | linux-2.6.25-regression linux-bugzilla-pending | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
/var/log/messages
kernel config xorg config dmesg after boot and nvidia driver and lateset gentoo-sources(2.27-r2),klibc(1.5.12-r1) and v86d (0.1.9) /var/log/messages dmesg after boat dmesg after boot dmesg after boot, memmap=16M@0xff0000 dmesg after boot, working uvesafb with kernel 2.6.24-r8 screenshot, memmap=exactmap memmap=16M@0xff0000 A patch for testvbe to display phys_base_ptr for all modes. |
||
|
Description
Oliver R
2008-08-03 15:36:34 UTC
Created attachment 162110 [details]
/var/log/messages
Created attachment 162112 [details]
kernel config
Created attachment 162114 [details]
xorg config
Can you reproduce this on the latest revision of gentoo-sources-2.6.27? (In reply to comment #4) > Can you reproduce this on the latest revision of gentoo-sources-2.6.27? > Hi Daniel, I can still reproduce it (It drives me crazy ;). I tried it with the latest gentoo-sources/klibc/v86d. I also tried compiling uvesafb as a module and then loading it via /etc/modules.autoload.d/kernel-2.6 but it didn't solve the problem :( I guess I am having the same problem than ... http://bugs.gentoo.org/show_bug.cgi?id=196848 Hope you can help. Thank's for everything... Oli Can you reproduce this if you don't use the closed source nvidia graphics driver? If so, please post "dmesg" output from after you boot up and start X. Created attachment 170528 [details]
dmesg after boot and nvidia driver and lateset gentoo-sources(2.27-r2),klibc(1.5.12-r1) and v86d (0.1.9)
Comment on attachment 170528 [details]
dmesg after boot and nvidia driver and lateset gentoo-sources(2.27-r2),klibc(1.5.12-r1) and v86d (0.1.9)
I still run into the same problem with both nv and nvidia driver, as well as uvesafb compiled as module and directly into the kernel....
Michal, any ideas? Oliver, could you please emerge v86d with the 'x86emu' USE flag and see whether this changes anything? (if uvesafb is compiled into the kernel, you will need to rebuild your kernel image after reinstalling v86d). Also, please only use the latest (unstable) versions of v86d and klibc when running the tests. hi Michal, I had tried it already with the flag 'x86emu' but that didn't help either. I just tried it with the latest configuration sys-kernel/gentoo-sources-2.6.27-r4 sys-apps/v86d-0.1.9 dev-libs/klibc-1.5.12-r1 x11-drivers/nvidia-drivers-177.80 It still runs into the following error... ############ uvesafb: NVIDIA Corporation, G84 Board - p403h05 - p403h05 , Chip Rev , OEM: NVIDIA, VBE v3.0 Nov 28 09:05:03 chef-rechner uvesafb: protected mode interface info at c000:b6e0 Nov 28 09:05:03 chef-rechner uvesafb: pmi: set display start = c00cb743, set palette = c00cb79e Nov 28 09:05:03 chef-rechner uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da Nov 28 09:05:03 chef-rechner uvesafb: VBIOS/hardware doesn't support DDC transfers Nov 28 09:05:03 chef-rechner uvesafb: no monitor limits have been set, default refresh rate will be used Nov 28 09:05:03 chef-rechner uvesafb: scrolling: ypan using protected mode interface, yres_virtual=11468 Nov 28 09:05:03 chef-rechner uvesafb: cannot reserve video memory at 0xff0000 Nov 28 09:05:03 chef-rechner uvesafb: probe of uvesafb.0 failed with error -5 ################# I am really wondering whether it has something to do with uvesafb. The error behaviour is really strange. Once I switch back to the framebuffer console, the monitor switches off and I can't get the computer back to work...I even can't (ctrl+alt+del) softboot the computer... This behaviour occurs, with all framebuffer drivers. Even vesafb...?!?!? Again, with linux-2.6.24-r8 everything works fine. Hope you guys can help.... Thanks so much...!!!!! Oli (In reply to comment #11) > Nov 28 09:05:03 chef-rechner uvesafb: cannot reserve video memory at 0xff0000 > Nov 28 09:05:03 chef-rechner uvesafb: probe of uvesafb.0 failed with error -5 This indicates that you are NOT using uvesafb. Could you please provide the output of `fbset -i` as well as the contents of /proc/iomem? hiii >fbset -i open /dev/fb0: No such file or directory > /proc/iomem 00000000-0009f7ff : System RAM 0009f800-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000cd1ff : Video ROM 000cd200-000cffff : pnp 00:0b 000f0000-000fffff : System ROM 00100000-7fedffff : System RAM 00100000-0040a0b8 : Kernel code 0040a0b9-0051a27b : Kernel data 00560000-005a09db : Kernel bss 7fee0000-7fee2fff : ACPI Non-volatile Storage 7fee3000-7feeffff : ACPI Tables 7fef0000-7fefffff : reserved 80000000-800fffff : PCI Bus #04 80000000-8001ffff : 0000:04:00.0 d0000000-dfffffff : PCI Bus #01 d0000000-dfffffff : 0000:01:00.0 e0000000-e3ffffff : PCI MMCONFIG 0 e0000000-e3ffffff : reserved e4000000-e7ffffff : PCI Bus #01 e4000000-e5ffffff : 0000:01:00.0 e6000000-e6ffffff : 0000:01:00.0 e6000000-e6ffffff : nvidia e7000000-e701ffff : 0000:01:00.0 e8000000-e9ffffff : PCI Bus #04 e9000000-e9000fff : 0000:04:00.0 e9000000-e9000fff : r8169 ea000000-ea0fffff : PCI Bus #03 ea000000-ea001fff : 0000:03:00.0 ea000000-ea001fff : ahci ea100000-ea1fffff : PCI Bus #05 ea100000-ea100fff : 0000:05:00.0 ea100000-ea100fff : bttv0 ea101000-ea101fff : 0000:05:00.1 ea101000-ea101fff : Bt87x audio ea200000-ea203fff : 0000:00:1b.0 ea200000-ea203fff : ICH HD audio ea204000-ea2043ff : 0000:00:1d.7 ea204000-ea2043ff : ehci_hcd ea205000-ea2053ff : 0000:00:1a.7 ea205000-ea2053ff : ehci_hcd ea206000-ea2060ff : 0000:00:1f.3 fec00000-ffffffff : reserved fed00000-fed003ff : HPET 0 (In reply to comment #13) > >fbset -i > open /dev/fb0: No such file or directory This seems to indicate that you are not using the framebuffer at all. Could you please double-check your kernel config (uvesafb should be the only framebuffer driver enabled), rebuild the kernel and provide a new kernel log that would contain _all_ messages logged after boot? (the 'dmesg' file you attached seems to be incomplete -- it's missing the initial part of the log). Created attachment 173699 [details]
/var/log/messages
Created attachment 173701 [details]
dmesg after boat
...I double checked and I definitely only use the uvesafb driver, built into the kernel... (In reply to comment #15) > Created an attachment (id=173699) [edit] > /var/log/messages This kernel log still seems incomplete. Instead of /var/log/messages, please attach the output of `dmesg`. Boot with log_buf_len=64k on the kernel command line to ensure that stuff doesn't get scrolled out of the log buffer. Created attachment 174668 [details]
dmesg after boot
...here is the complete dmesg with log_buf_len=64k...hope that helps...
My 5 cents. I found it funny that klibc-1.5.12-r1 compile against gentoo-sources-2.6.26, while I have 2.6.27 installed and in use. (In reply to comment #19) > Created an attachment (id=174668) [edit] > dmesg after boot > > ...here is the complete dmesg with log_buf_len=64k...hope that helps... It does :) Could you please boot with 'memmap=16M@0xff0000' on your kernel command line and see if this makes it possible for uvesafb to work? If not, could you please post a new kernel log, with both that option and log_buf_len=64k active? Does uvesafb work for you with the old kernels (2.6.24*) or did you use vesafb with them? If you used uvesafb, could you please post a kernel log from 2.6.24 as well? Created attachment 175000 [details]
dmesg after boot, memmap=16M@0xff0000
...the command line parameter memmap=16M@0xff0000, still produces the same results...
Created attachment 175002 [details]
dmesg after boot, working uvesafb with kernel 2.6.24-r8
...with kernel 2.6.24-r8 uvesafb works like a charme... ;)
For the memmap option, it looks like I misunderstood the kernel docs when I suggested it. What you'd need for it to have any effect seems to be "memmap=exactmap memmap=16M@0xff0000". Could you please try that and post the kernel log in case it doesn't work? What is interesting though is that the address uvesafb tries to use is totally different in 2.6.24 than in 2.6.27. I'll see about creating a patch to gather some more debugging data. Created attachment 175006 [details]
screenshot, memmap=exactmap memmap=16M@0xff0000
...now my computer hang, directly after lilo finished, with the command line parameter memmap=exactmap memmap=16M@0xff0000
Comment on attachment 175006 [details]
screenshot, memmap=exactmap memmap=16M@0xff0000
...now my computer hung, directly after lilo finished, with the command line
parameter memmap=exactmap memmap=16M@0xff0000
Created attachment 175185 [details, diff]
A patch for testvbe to display phys_base_ptr for all modes.
Could you please apply this patch to v86d, build it manually with --with-debug or via the ebuild with USE="debug" and post the output of the patched `testvbe`?
...here is the output... VBE Version: 3.00 OEM String: NVIDIA OEM Vendor Name: NVIDIA Corporation OEM Prod. Name: G84 Board - p403h05 - p403h05 OEM Prod. Rev: Chip Rev ID attr mode --------------------------- 0100 03bf 640x400-8 ff0000 0101 03bf 640x480-8 ff0000 0102 033f 800x600-4 0 0103 03bf 800x600-8 ff0000 0104 033f 1024x768-4 0 0105 03bf 1024x768-8 ff0000 0106 033f 1280x1024-4 0 0107 03bf 1280x1024-8 ff0000 010e 03bf 320x200-16 ff0000 010f 03bf 320x200-32 ff0000 0111 03bf 640x480-16 ff0000 0112 03bf 640x480-32 ff0000 0114 03bf 800x600-16 ff0000 0115 03bf 800x600-32 ff0000 0117 03bf 1024x768-16 ff0000 0118 03bf 1024x768-32 ff0000 011a 03bf 1280x1024-16 ff0000 011b 03bf 1280x1024-32 ff0000 0130 03bf 320x200-8 ff0000 0131 03bf 320x400-8 ff0000 0132 03bf 320x400-16 ff0000 0133 03bf 320x400-32 ff0000 0134 03bf 320x240-8 ff0000 0135 03bf 320x240-16 ff0000 0136 03bf 320x240-32 ff0000 013d 03bf 640x400-16 ff0000 013e 03bf 640x400-32 ff0000 0145 03bf 1600x1200-8 ff0000 0146 03bf 1600x1200-16 ff0000 014a 03bf 1600x1200-32 ff0000 Thanks for the output with the debug info. Have you ever tried to use the old kernel that works for you (linux-2.6.24-r8) with the latest version of v86d? If not, could you please try to do that? I'd like to determine whether the problem is in userspace or in kernelspace. hi Michal, the latest v86d works just fine with the old kernel 2.6.24-r8. The testvbe prints the following for it... 0100 03bf 640x400-8 e5000000 0101 03bf 640x480-8 e5000000 0102 033f 800x600-4 0 0103 03bf 800x600-8 e5000000 0104 033f 1024x768-4 0 0105 03bf 1024x768-8 e5000000 0106 033f 1280x1024-4 0 0107 03bf 1280x1024-8 e5000000 010e 03bf 320x200-16 e5000000 010f 03bf 320x200-32 e5000000 0111 03bf 640x480-16 e5000000 0112 03bf 640x480-32 e5000000 0114 03bf 800x600-16 e5000000 0115 03bf 800x600-32 e5000000 0117 03bf 1024x768-16 e5000000 0118 03bf 1024x768-32 e5000000 011a 03bf 1280x1024-16 e5000000 011b 03bf 1280x1024-32 e5000000 0130 03bf 320x200-8 e5000000 0131 03bf 320x400-8 e5000000 0132 03bf 320x400-16 e5000000 0133 03bf 320x400-32 e5000000 0134 03bf 320x240-8 e5000000 0135 03bf 320x240-16 e5000000 0136 03bf 320x240-32 e5000000 013d 03bf 640x400-16 e5000000 013e 03bf 640x400-32 e5000000 0145 03bf 1600x1200-8 e5000000 0146 03bf 1600x1200-16 e5000000 014a 03bf 1600x1200-32 e5000000 (In reply to comment #30) > the latest v86d works just fine with the old kernel 2.6.24-r8. It looks like the problem is in the kernel space then. Are the kernel configs that you are using for 2.6.24 and for the newer kernel more or less the same (up to default changes that are introduced during updates)? If they are, you will need to do a 'git bisect' search to try to find the offending change in the kernel. Please have a look at: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html for some info about git-bisect and let me know in case you have any questions. Alternatively or in addition you may want to consult http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ on how to do the bisection. In your case, you should check out git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git since you know the regression exists in the 2.6.25.y stable tree. And because gentoo-sources-2.6.25-r7 are based on 2.6.25.11 you would start out like this ... # git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git \ linux-git # cd linux-git # git bisect start # git bisect bad v2.6.25.11 # git bisect good v2.6.24 ...here is the resulting patch...I love binary search ;) Thanks Axel for the link... b6ce068a1285a24185b01be8a49021827516b3e1 is first bad commit commit b6ce068a1285a24185b01be8a49021827516b3e1 Author: Matthew Wilcox <matthew@wil.cx> Date: Sun Feb 10 09:45:28 2008 -0500 Change pci_raw_ops to pci_raw_read/write We want to allow different implementations of pci_raw_ops for standard and extended config space on x86. Rather than clutter generic code with knowledge of this, we make pci_raw_ops private to x86 and use it to implement the new raw interface -- raw_pci_read() and raw_pci_write(). Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> :040000 040000 37d93a98a615234529e980755a88c05cc1a5dfb3 0b0e3a803a908659f9952e872b65a532853bfd42 M arch :040000 040000 1fbea4ab6a9f98c4a0930491f9e742c7288b42ed 22d078ce9c816d4b3c738a77ce198118f4a8ab47 M drivers :040000 040000 aa7650863cb046eb3f20c63db246739a3dd59403 34603b3c47eb462b0eecaac626d724385ce946f4 M include The corresponding link to gitweb http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=commit;h=b6ce068a1285a24185b01be8a49021827516b3e1 which is one of the very last commits that made it into 2.6.25-rc1 ...thanks Axel, I guess my freez must be then somehow related to the PCI/ACPI exception I get... ### PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 63 PCI: Not using MMCONFIG. PCI: Fatal: No config space access function found ACPI: EC: Look up EC in DSDT ACPI Exception (evregion-0419): AE_ERROR, Returned by Handler for [PCI_Config] [20080609] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.LNKA._STA] (Node f7816f78), AE_ERROR ACPI Error (uteval-0232): Method execution failed [\_SB_.PCI0.LNKA._STA] (Node f7816f78), AE_ERROR ACPI Exception (evregion-0419): AE_ERROR, Returned by Handler for [PCI_Config] [20080609] #### (In reply to comment #35) > ### > PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 63 > PCI: Not using MMCONFIG. > PCI: Fatal: No config space access function found > ### Could you please open an upstream bug on http://bugzilla.kernel.org/ for this issue? In the bug please do the following: - describe the initial problem (invalid phys_base_ptr is reported by the Video BIOS for all modes), - point out the commit which introduces the problem, - link to this bug for reference purposes, - paste the relevant parts of the kernel logs (e.g. the part quoted above), - add me (spock@gentoo.org) to the CC list. ... and don't forget to attach you kernel config. It might also make sense to point out that the onyl PCI access mode configured for the kernel is MMCONFIG. Please reopen this bug when you've filed upstream I found the problem. It was a wrong PCI Access mode configuration in the kernel. I used MMConfig, which seems not to work on my Gigabyte GA-P35-DS3(Rev 2.0). The "Bios" setting works perfectly ;) CONFIG_PCI_GOBIOS=y # CONFIG_PCI_GOMMCONFIG is not set Thanks for all the help!!!!!! |
