Re: [ACPI] Call for help: list of machines with working S3
Am Freitag, 18. Februar 2005 14:38 schrieb Norbert Preining: > On Fre, 18 Feb 2005, Norbert Preining wrote: > > I tried: > > 2.6.11-rc3-mm2 + Xorg + DRI disabled > > and this works. > > > > I cannot enable dri/drm with the cvs version of the drm modules, because > > the drm modules do not compile for -mm kernels, since there is the patch > > for multiple agp bridges included (that's the reason why I tried -rc4 > > Final observation: After patching in the changes from mm kernels for > multiple agp bridges to the drm-source code (the patch > drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch from the > broken out archive) I could compile the drm-trunk-src modules. > > So now I am running with 2.6.11-rc3-mm2 + Xorg + DRI enabled (and > working) with the drm modules from drm-trunk-module-src. > > Outcome: freeze when switching to X. As with the other modules (in fact > I think that most of the changes to the drm stuff are included in the mm > kernel, so this should not change anything, as mm pulls from bk-agpgart, > bk-drm-via) a funny screen, and the CapsLock light is blinking. Kernel panik. Can you ssh into your maschine and get a dmesg? I recommend you to write to the dri devs. Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Donnerstag, 17. Februar 2005 20:08 schrieb Norbert Preining: > On Die, 15 Feb 2005, Stefan Dösinger wrote: > > > - DRI must be disabled I guess?! Even with newer X server (x.org)? > > > > Do you use the fglrx driver? This doesn't work with any type of suspend > > so far. If you use the radeon driver try a driver update. > > Ok, I installed xlibmesa-gl1-dri-trunk, xserver-xfree86-dri-trunk and > compiled linux-2.6.11-rc4 and drm modules from drm-trunk-module-src, all > from http://www.nixnuts.net/files/ > > But I had no success whatsoever. With this (Xorg server, current dri/drm > stuff, ..) the laptop not even wakes up from sleep! Sorry, no Idea. What about 2.6.11-rc3-mm2 + Xorg 6.8.1.99? Did you test this combination? Am I right with assuming that resumeworked after the X upgrade if X wasn't started before suspend? Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Mittwoch, 16. Februar 2005 16:06 schrieb Carl-Daniel Hailfinger: > Stefan Dösinger schrieb: > >>The problems with this patch are: > >>- you need to press a key to come back from the "resume-console" after > >>resume. - DRI in X does not work (at least for me with intel-agp, others > >>reportet it works) > >>I just disabloed it by not loading intel-agp (hotplug-blacklist) > > > > You can force the radeon X driver to use pci mode by setting Option > > "ForcePciMode" to "true" or something simmilar in you X config file. This > > way you can get dri without intel-agp. This is much slower, but enought > > to play tuxracer ;-) > > How do I enable DRI with my card to test that crash? I have the > following in my XF86Config: > > Section "DRI" > Group "video" > Mode 0660 > EndSection > > but nothing else about DRI. So do I have to change something in > my configuration? > > Oh, and could you please include run "lspci -vv" and include the > part about VGA compatible controller in your mail? I have some > hypothesis about the settings there having to do with resume. You can set Option "BusType" "PCI" in your cards driver section in xorg.conf / XF86Config. With this setting you should get DRI without having intel-agp loaded(if the rest is set up correctly) My lspci output is: :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Reset- FastB2B- :00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- :00:1f.0 ISA bridge: Intel Corp. 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at 1860 [size=16] Region 5: Memory at 2000 (32-bit, non-prefetchable) [size=1K] :00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset+ 16bInt+ PostWrite- 16-bit legacy interface ports at 0001 :02:06.1 CardBus bridge: O2 Micro, Inc. OZ711M1 SmartCardBus MultiMediaBay Controller (rev 20) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt- PostWrite- 16-bit legacy interface ports at 0001 :02:06.2 System peripheral: O2 Micro, Inc. OZ711Mx MultiMediaBay Accelerator Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
> The problems with this patch are: > - you need to press a key to come back from the "resume-console" after > resume. - DRI in X does not work (at least for me with intel-agp, others > reportet it works) > I just disabloed it by not loading intel-agp (hotplug-blacklist) You can force the radeon X driver to use pci mode by setting Option "ForcePciMode" to "true" or something simmilar in you X config file. This way you can get dri without intel-agp. This is much slower, but enought to play tuxracer ;-) Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
The problems with this patch are: - you need to press a key to come back from the resume-console after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) You can force the radeon X driver to use pci mode by setting Option ForcePciMode to true or something simmilar in you X config file. This way you can get dri without intel-agp. This is much slower, but enought to play tuxracer ;-) Stefan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Call for help: list of machines with working S3
Am Mittwoch, 16. Februar 2005 16:06 schrieb Carl-Daniel Hailfinger: Stefan Dösinger schrieb: The problems with this patch are: - you need to press a key to come back from the resume-console after resume. - DRI in X does not work (at least for me with intel-agp, others reportet it works) I just disabloed it by not loading intel-agp (hotplug-blacklist) You can force the radeon X driver to use pci mode by setting Option ForcePciMode to true or something simmilar in you X config file. This way you can get dri without intel-agp. This is much slower, but enought to play tuxracer ;-) How do I enable DRI with my card to test that crash? I have the following in my XF86Config: Section DRI Group video Mode 0660 EndSection but nothing else about DRI. So do I have to change something in my configuration? Oh, and could you please include run lspci -vv and include the part about VGA compatible controller in your mail? I have some hypothesis about the settings there having to do with resume. You can set Option BusType PCI in your cards driver section in xorg.conf / XF86Config. With this setting you should get DRI without having intel-agp loaded(if the rest is set up correctly) My lspci output is: :00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Region 0: Memory at e000 (32-bit, prefetchable) Capabilities: [e4] #09 [f104] Capabilities: [a0] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW+ Rate=x4 :00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 96 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 3000-3fff Memory behind bridge: d010-d01f Prefetchable memory behind bridge: d800-dfff Expansion ROM at 3000 [disabled] [size=4K] BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B- :00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 10 Region 4: I/O ports at 1800 [size=32] :00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) (prog-if 00 [UHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin B routed to IRQ 10 Region 4: I/O ports at 1820 [size=32] :00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin C routed to IRQ 10 Region 4: I/O ports at 1840 [size=32] :00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI]) Subsystem: Acer Incorporated [ALI]: Unknown device 001f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin D routed to IRQ 10 Region 0: Memory at d000 (32-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] #0a [2080] :00:1e.0 PCI bridge: Intel Corp. 82801 Mobile PCI Bridge (rev 83) (prog-if 00
Re: [ACPI] Call for help: list of machines with working S3
Am Dienstag, 15. Februar 2005 18:08 schrieb Norbert Preining: > On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote: > > To suspend and resume properly, call the following script as root: > > Success. > > After deactivating DRI in the X config file and saving the states with > your script (thanks) and turning off various stuff I get X running > again. > > Questions: > - DRI must be disabled I guess?! Even with newer X server (x.org)? Do you use the fglrx driver? This doesn't work with any type of suspend so far. If you use the radeon driver try a driver update. Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC] Reliable video POSTing on resume
Am Samstag, 5. Februar 2005 18:38 schrieb Jon Smirl: > On Sat, 5 Feb 2005 17:48:43 +0100, Stefan Dösinger > > <[EMAIL PROTECTED]> wrote: > > The reset code of radeon card seems to be easy to reverse engineer. I > > have started an attempt and I have 50-60% of my radeon M9 reset code > > implemented in a 32 bit C program. I had to stop due to school reasons. > > The problem with the radeon reset code is that there are many, many > variations of the radeon chips, including different steppings of the > same part. The ROM is matched to the paticular bugs of the chip. From > what I know ATI doesn't even have a universal radeon reset program. I don't think they differ a lot. Does anybody know how the Win32 driver resets the card? If it calls 0xc000:3 it will also have the problem with overwritten reset code, and if it has it's own reset routine the cards can't differ a lot. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC] Reliable video POSTing on resume
Am Samstag, 5. Februar 2005 18:38 schrieb Jon Smirl: On Sat, 5 Feb 2005 17:48:43 +0100, Stefan Dösinger [EMAIL PROTECTED] wrote: The reset code of radeon card seems to be easy to reverse engineer. I have started an attempt and I have 50-60% of my radeon M9 reset code implemented in a 32 bit C program. I had to stop due to school reasons. The problem with the radeon reset code is that there are many, many variations of the radeon chips, including different steppings of the same part. The ROM is matched to the paticular bugs of the chip. From what I know ATI doesn't even have a universal radeon reset program. I don't think they differ a lot. Does anybody know how the Win32 driver resets the card? If it calls 0xc000:3 it will also have the problem with overwritten reset code, and if it has it's own reset routine the cards can't differ a lot. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC] Reliable video POSTing on resume
Am Samstag, 5. Februar 2005 16:47 schrieb Jon Smirl: > On Sat, 05 Feb 2005 12:53:37 +0100, Ondrej Zary > > <[EMAIL PROTECTED]> wrote: > > I wonder how this can work: > > a motherboard with i815 chipset (integrated VGA), Video BIOS is > > integrated into system BIOS > > a PCI card inserted into one of the PCI slots, configured as primary in > > system BIOS > > The info needed to initialize Intel chips is public. The info needed > to initialize most Nvidia and ATI chips is not. DID someone ask ATI or Nvidia for this? I have the impression that everyone says ati doesn't help, but no one tried to get help so far. The reset code of radeon card seems to be easy to reverse engineer. I have started an attempt and I have 50-60% of my radeon M9 reset code implemented in a 32 bit C program. I had to stop due to school reasons. My radeonreset kernel module turns the backlight off and seems to reset the card's memory. I consider it dangerous because I don't know what it really does because I don't have the card's specs. A owner of an radeon M6 card tried my code too and it worked in the same way as on my M9 card, so I think the reset procedure is the same on all radeon cards. I think with some comparison of the reset code and the specs that the DRI/X.org/XFree developers have we can write a working reset code for radeon cards. This won't help users of non-radeon cards of course :-( ATI is aware of suspend/resume problems with their fglrx driver(see http://www.ati.com/support/infobase/4746.html). I've written a few notes to them, but I haven't got a reply so far(But they also told me not to expect one). The power management code in radeon_pm.c seems to be written by ATI. Alltogether I'd not call the situation hopeless. Cheers, Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ACPI] Re: [RFC] Reliable video POSTing on resume
Am Samstag, 5. Februar 2005 16:47 schrieb Jon Smirl: On Sat, 05 Feb 2005 12:53:37 +0100, Ondrej Zary [EMAIL PROTECTED] wrote: I wonder how this can work: a motherboard with i815 chipset (integrated VGA), Video BIOS is integrated into system BIOS a PCI card inserted into one of the PCI slots, configured as primary in system BIOS The info needed to initialize Intel chips is public. The info needed to initialize most Nvidia and ATI chips is not. DID someone ask ATI or Nvidia for this? I have the impression that everyone says ati doesn't help, but no one tried to get help so far. The reset code of radeon card seems to be easy to reverse engineer. I have started an attempt and I have 50-60% of my radeon M9 reset code implemented in a 32 bit C program. I had to stop due to school reasons. My radeonreset kernel module turns the backlight off and seems to reset the card's memory. I consider it dangerous because I don't know what it really does because I don't have the card's specs. A owner of an radeon M6 card tried my code too and it worked in the same way as on my M9 card, so I think the reset procedure is the same on all radeon cards. I think with some comparison of the reset code and the specs that the DRI/X.org/XFree developers have we can write a working reset code for radeon cards. This won't help users of non-radeon cards of course :-( ATI is aware of suspend/resume problems with their fglrx driver(see http://www.ati.com/support/infobase/4746.html). I've written a few notes to them, but I haven't got a reply so far(But they also told me not to expect one). The power management code in radeon_pm.c seems to be written by ATI. Alltogether I'd not call the situation hopeless. Cheers, Stefan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
