* Radeon M7 and resuming from suspend-to-ram
@ 2005-01-14 14:12 Tomi Kallio
[not found] ` <41E7D334.6060003-y4dnIKzCb/d9YMlOZIriJw@public.gmane.org>
0 siblings, 1 reply; 12+ messages in thread
From: Tomi Kallio @ 2005-01-14 14:12 UTC (permalink / raw)
To: gentoo-user, acpi-devel
Hello.
I'm running gentoo on Compaq Evo N800V laptop with radeon M7. At the
moment I'm using gentoo-dev-sources version 2.6.10-r4. For the first
time suspend-to-ram almoust works but I'm having trouble resuming
radeon/screen. After resuming, display on laptop stays black with just
"weak" backlight but if I plug in external monitor, then external
monitor is working normally but laptop's display stays black. So the
resume from X "works". If I switch to console then external monitor
complaints about invalid mode while laptop's display stays black. With
radeontool I can normally power down/up external output, but display on
laptop stays blank no matter what I do. I have also tried boot-radeon in
console that should reset video bios, but it doesn't work either.
Any ideas?
Tomi
--
gentoo-user@gentoo.org mailing list
^ permalink raw reply [flat|nested] 12+ messages in thread[parent not found: <41E7D334.6060003-y4dnIKzCb/d9YMlOZIriJw@public.gmane.org>]
* Re: Radeon M7 and resuming from suspend-to-ram [not found] ` <41E7D334.6060003-y4dnIKzCb/d9YMlOZIriJw@public.gmane.org> @ 2005-01-14 15:26 ` Jeremy Moles 2005-01-14 20:06 ` Tomi Kallio 2005-01-14 16:24 ` Karol Kozimor 2005-01-14 17:31 ` Matthew Garrett 2 siblings, 1 reply; 12+ messages in thread From: Jeremy Moles @ 2005-01-14 15:26 UTC (permalink / raw) To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Probably already tried this but: Here at work we use an ACPID script that simply runs "radeontool light on" after a resume. Also, you might trying "chvt 1" or similar before suspend and chvt'ing back to whatever TTY X is on upon resume. That's worked sometimes too. On Fri, 2005-01-14 at 16:12 +0200, Tomi Kallio wrote: > Hello. > > I'm running gentoo on Compaq Evo N800V laptop with radeon M7. At the > moment I'm using gentoo-dev-sources version 2.6.10-r4. For the first > time suspend-to-ram almoust works but I'm having trouble resuming > radeon/screen. After resuming, display on laptop stays black with just > "weak" backlight but if I plug in external monitor, then external > monitor is working normally but laptop's display stays black. So the > resume from X "works". If I switch to console then external monitor > complaints about invalid mode while laptop's display stays black. With > radeontool I can normally power down/up external output, but display on > laptop stays blank no matter what I do. I have also tried boot-radeon in > console that should reset video bios, but it doesn't work either. > > Any ideas? > > Tomi > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Acpi-devel mailing list > Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/acpi-devel ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Radeon M7 and resuming from suspend-to-ram 2005-01-14 15:26 ` Jeremy Moles @ 2005-01-14 20:06 ` Tomi Kallio 0 siblings, 0 replies; 12+ messages in thread From: Tomi Kallio @ 2005-01-14 20:06 UTC (permalink / raw) To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f > Probably already tried this but: > > Here at work we use an ACPID script that simply runs "radeontool light > on" after a resume. Also, you might trying "chvt 1" or similar before > suspend and chvt'ing back to whatever TTY X is on upon resume. I tried "radeontool light on", but it has no effect. When using external display I'm able to power it off using radeontool. At the moment resume from suspend-to-ram works from X (xorg and Gentoo's patches) using external display and suspend/resume from X is enough for me. Only problem is that I'm unable to get laptop's own display working after resume, only external works. Tomi ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Radeon M7 and resuming from suspend-to-ram [not found] ` <41E7D334.6060003-y4dnIKzCb/d9YMlOZIriJw@public.gmane.org> 2005-01-14 15:26 ` Jeremy Moles @ 2005-01-14 16:24 ` Karol Kozimor [not found] ` <20050114162359.GA22184-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org> 2005-01-14 17:31 ` Matthew Garrett 2 siblings, 1 reply; 12+ messages in thread From: Karol Kozimor @ 2005-01-14 16:24 UTC (permalink / raw) To: Tomi Kallio Cc: gentoo-user-cnFmAm88PdgLnqt3yJz4RQ, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Thus wrote Tomi Kallio: > I'm running gentoo on Compaq Evo N800V laptop with radeon M7. At the acpi_sleep=s3_bios helps here (ASUS L3C, Radeon M7), have you checked Documentation/power/video.txt? Best regards, -- Karol 'sziwan' Kozimor sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <20050114162359.GA22184-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>]
* Re: Radeon M7 and resuming from suspend-to-ram [not found] ` <20050114162359.GA22184-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org> @ 2005-01-14 19:53 ` Tomi Kallio 0 siblings, 0 replies; 12+ messages in thread From: Tomi Kallio @ 2005-01-14 19:53 UTC (permalink / raw) To: Karol Kozimor; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f >>I'm running gentoo on Compaq Evo N800V laptop with radeon M7. At the >> > acpi_sleep=s3_bios helps here (ASUS L3C, Radeon M7), have you checked > Documentation/power/video.txt? I tried acpi_sleep=s3_bios, but it crashed during resume. Without any options resume works when using external display but laptops own display stays black, whether external display is connected or not. Tomi ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Radeon M7 and resuming from suspend-to-ram [not found] ` <41E7D334.6060003-y4dnIKzCb/d9YMlOZIriJw@public.gmane.org> 2005-01-14 15:26 ` Jeremy Moles 2005-01-14 16:24 ` Karol Kozimor @ 2005-01-14 17:31 ` Matthew Garrett [not found] ` <1105723866.28126.10.camel-Xmbc1Sz64/5pghhO6/9/sx2eb7JE58TQ@public.gmane.org> 2 siblings, 1 reply; 12+ messages in thread From: Matthew Garrett @ 2005-01-14 17:31 UTC (permalink / raw) To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Fri, 2005-01-14 at 16:12 +0200, Tomi Kallio wrote: > Any ideas? Try getting vbetool from http://www.srcf.ucam.org/~mjg59/vbetool and build it. On boot (before X is started), do vbetool vbestate save >/var/run/vbestate In your suspend script, chvt away from X. In your resume script, run vbetool vbestate restore </var/run/vbestate vbetool dpms on and then chvt back to X. That seems to work on a large number of machines. -- Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <1105723866.28126.10.camel-Xmbc1Sz64/5pghhO6/9/sx2eb7JE58TQ@public.gmane.org>]
* Re: Radeon M7 and resuming from suspend-to-ram [not found] ` <1105723866.28126.10.camel-Xmbc1Sz64/5pghhO6/9/sx2eb7JE58TQ@public.gmane.org> @ 2005-01-18 22:11 ` Ralf Gerbig [not found] ` <87k6qal75i.fsf-news-ihuhiKcgPLSELgA04lAiVw@public.gmane.org> 0 siblings, 1 reply; 12+ messages in thread From: Ralf Gerbig @ 2005-01-18 22:11 UTC (permalink / raw) To: Matthew Garrett; +Cc: acpi-devel * Matthew Garrett writes: > Try getting vbetool from http://www.srcf.ucam.org/~mjg59/vbetool and > build it. On boot (before X is started), do Dammit, it does work on my Acer Travelmate 380. It took some idiot hacks to compile on SuSE, but after calling chvt 1 vbetool vbestate save > /tmp/vbestate in /usr/lib/poewersave/scripts/prepare_suspend_to_ram and vbetool vbestate restore < /tmp/vbestate chvt 7 in /usr/lib/poewersave/scripts/restore_after_suspend_to_ram the LCD becomes alive after suspend to ram. Thanks for the good stuff, Ralf -- P: Linus Torvalds patch-2.2.4 -S: Buried alive in diapers +S: Buried alive in reporters ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <87k6qal75i.fsf-news-ihuhiKcgPLSELgA04lAiVw@public.gmane.org>]
* Re: Radeon M7 and resuming from suspend-to-ram [not found] ` <87k6qal75i.fsf-news-ihuhiKcgPLSELgA04lAiVw@public.gmane.org> @ 2005-01-19 0:46 ` Matthew Garrett 2005-01-19 20:07 ` Ralf Gerbig 0 siblings, 1 reply; 12+ messages in thread From: Matthew Garrett @ 2005-01-19 0:46 UTC (permalink / raw) To: acpi-devel On Tue, 2005-01-18 at 23:11 +0100, Ralf Gerbig wrote: > chvt 1 > vbetool vbestate save > /tmp/vbestate > > in /usr/lib/poewersave/scripts/prepare_suspend_to_ram and > > vbetool vbestate restore < /tmp/vbestate > chvt 7 > > in /usr/lib/poewersave/scripts/restore_after_suspend_to_ram > > the LCD becomes alive after suspend to ram. Excellent. So far, the best solution we've found is to save the vbestate on boot rather than on suspend. There's a small number of machines that this hangs on, irritatingly, but I'm trying to track them down. It seems far more successful than using video_post for the most part. -- Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Radeon M7 and resuming from suspend-to-ram 2005-01-19 0:46 ` Matthew Garrett @ 2005-01-19 20:07 ` Ralf Gerbig [not found] ` <87ekghkwt0.fsf-news-ihuhiKcgPLSELgA04lAiVw@public.gmane.org> 0 siblings, 1 reply; 12+ messages in thread From: Ralf Gerbig @ 2005-01-19 20:07 UTC (permalink / raw) To: acpi-devel * Matthew Garrett writes: > On Tue, 2005-01-18 at 23:11 +0100, Ralf Gerbig wrote: >> chvt 1 >> vbetool vbestate save > /tmp/vbestate >> >> in /usr/lib/poewersave/scripts/prepare_suspend_to_ram and >> >> vbetool vbestate restore < /tmp/vbestate >> chvt 7 >> >> in /usr/lib/poewersave/scripts/restore_after_suspend_to_ram >> >> the LCD becomes alive after suspend to ram. > Excellent. So far, the best solution we've found is to save the vbestate > on boot rather than on suspend. There's a small number of machines that > this hangs on, irritatingly, but I'm trying to track them down. It seems > far more successful than using video_post for the most part. Last night I was too dumbfounded that it actually worked to include any details. The thing is an Acer Travelmate 380: rge@lapdog2:~> /sbin/lspci 0000:00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02) 0000:00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02) 0000:00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02) 0000:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) 0000:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) 0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) 0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) 0000:00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) 0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 03) 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 83) 0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03) 0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 03) 0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) 0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) 0000:00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03) 0000:02:01.0 Network controller: Intel Corp. PRO/Wireless 2200BG (rev 05) 0000:02:09.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller 0000:02:09.2 FireWire (IEEE 1394): Texas Instruments PCI7x20 1394a-2000 OHCI Two-Port PHY/Link-Layer Controller 0000:02:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) rge@lapdog2:~> /sbin/lspci -n 0000:00:00.0 Class 0600: 8086:3580 (rev 02) 0000:00:00.1 Class 0880: 8086:3584 (rev 02) 0000:00:00.3 Class 0880: 8086:3585 (rev 02) 0000:00:02.0 Class 0300: 8086:3582 (rev 02) 0000:00:02.1 Class 0380: 8086:3582 (rev 02) 0000:00:1d.0 Class 0c03: 8086:24c2 (rev 03) 0000:00:1d.1 Class 0c03: 8086:24c4 (rev 03) 0000:00:1d.2 Class 0c03: 8086:24c7 (rev 03) 0000:00:1d.7 Class 0c03: 8086:24cd (rev 03) 0000:00:1e.0 Class 0604: 8086:2448 (rev 83) 0000:00:1f.0 Class 0601: 8086:24cc (rev 03) 0000:00:1f.1 Class 0101: 8086:24ca (rev 03) 0000:00:1f.3 Class 0c05: 8086:24c3 (rev 03) 0000:00:1f.5 Class 0401: 8086:24c5 (rev 03) 0000:00:1f.6 Class 0703: 8086:24c6 (rev 03) 0000:02:01.0 Class 0280: 8086:4220 (rev 05) 0000:02:09.0 Class 0607: 104c:ac8e 0000:02:09.2 Class 0c00: 104c:802e 0000:02:0a.0 Class 0200: 10ec:8139 (rev 10) Kernel is 2.6.11-rc1-mm1, Distribution SuSE 9.2 gcc version 3.3.4 (pre 3.3.5 20040809) SuSE does not have a shared libpci, only static so the precompiled binary unsurprisingly did not work. Compiling the source I got: rge@lapdog2:/usr/src/vbetool-0.2> make if gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"vbetool\" -DVERSION=\"0.2\" -I. -I. -g -Wall -Werror -pedantic -g -O2 -MT vbetool.o -MD -MP -MF ".deps/vbetool.Tpo" \ -c -o vbetool.o `test -f 'vbetool.c' || echo './'`vbetool.c; \ then mv -f ".deps/vbetool.Tpo" ".deps/vbetool.Po"; \ else rm -f ".deps/vbetool.Tpo"; exit 1; \ fi In file included from /usr/include/stdlib.h:416, from vbetool.c:14: /usr/include/sys/types.h:62: error: conflicting types for `dev_t' /usr/include/linux/types.h:22: error: previous declaration of `dev_t' /usr/include/sys/types.h:67: error: conflicting types for `gid_t' /usr/include/linux/types.h:52: error: previous declaration of `gid_t' /usr/include/sys/types.h:72: error: conflicting types for `mode_t' /usr/include/linux/types.h:24: error: previous declaration of `mode_t' /usr/include/sys/types.h:77: error: conflicting types for `nlink_t' /usr/include/linux/types.h:25: error: previous declaration of `nlink_t' /usr/include/sys/types.h:82: error: conflicting types for `uid_t' /usr/include/linux/types.h:51: error: previous declaration of `uid_t' In file included from /usr/include/sys/types.h:216, from /usr/include/stdlib.h:416, from vbetool.c:14: /usr/include/sys/select.h:78: error: conflicting types for `fd_set' /usr/include/linux/types.h:21: error: previous declaration of `fd_set' stdlib.h:415-416: #if defined __USE_SVID || defined __USE_XOPEN_EXTENDED || defined __USE_BSD # include <sys/types.h> /* we need int32_t... */ after fuzing around with -D, I temporally commented out the include. Thereafter adding -lpci to the end of the link command, I got a working executable. Ralf -- P: Linus Torvalds patch-2.2.4 -S: Buried alive in diapers +S: Buried alive in reporters ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <87ekghkwt0.fsf-news-ihuhiKcgPLSELgA04lAiVw@public.gmane.org>]
* Re: Radeon M7 and resuming from suspend-to-ram [not found] ` <87ekghkwt0.fsf-news-ihuhiKcgPLSELgA04lAiVw@public.gmane.org> @ 2005-02-03 21:07 ` Carl-Daniel Hailfinger [not found] ` <42029281.3070207-hi6Y0CQ0nG0@public.gmane.org> 0 siblings, 1 reply; 12+ messages in thread From: Carl-Daniel Hailfinger @ 2005-02-03 21:07 UTC (permalink / raw) To: Ralf Gerbig; +Cc: acpi-devel Ralf Gerbig schrieb: > * Matthew Garrett writes: > >>On Tue, 2005-01-18 at 23:11 +0100, Ralf Gerbig wrote: >> >>>chvt 1 >>>vbetool vbestate save > /tmp/vbestate >>> >>>in /usr/lib/poewersave/scripts/prepare_suspend_to_ram and >>> >>>vbetool vbestate restore < /tmp/vbestate >>>chvt 7 >>> >>>in /usr/lib/poewersave/scripts/restore_after_suspend_to_ram >>> >>>the LCD becomes alive after suspend to ram. > > >>Excellent. So far, the best solution we've found is to save the vbestate >>on boot rather than on suspend. There's a small number of machines that >>this hangs on, irritatingly, but I'm trying to track them down. It seems >>far more successful than using video_post for the most part. > > > Last night I was too dumbfounded that it actually worked to include > any details. > [...] > > SuSE does not have a shared libpci, only static so the precompiled > binary unsurprisingly did not work. > > Compiling the source I got: > > rge@lapdog2:/usr/src/vbetool-0.2> make > if gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"vbetool\" > -DVERSION=\"0.2\" -I. -I. > -g -Wall -Werror -pedantic -g -O2 -MT vbetool.o -MD -MP -MF ".deps/vbetool.Tpo" \ > -c -o vbetool.o `test -f 'vbetool.c' || echo './'`vbetool.c; \ > then mv -f ".deps/vbetool.Tpo" ".deps/vbetool.Po"; \ > else rm -f ".deps/vbetool.Tpo"; exit 1; \ > fi > In file included from /usr/include/stdlib.h:416, > from vbetool.c:14: > /usr/include/sys/types.h:62: error: conflicting types for `dev_t' > /usr/include/linux/types.h:22: error: previous declaration of `dev_t' > [...] Yes, the pci.h shipped by SUSE has problems. Simply move the #include <pci/pci.h> from the beginning to directly before #include <sys/kd.h> > after fuzing around with -D, I temporally commented out the > include. Thereafter adding -lpci to the end of the link command, I got > a working executable. This is a bug in Makefile.am. Pseudo-diff: -AM_LDFLAGS = -lpci +LIBS = -lpci Then run aclocal, autoconf and automake again. Regards, Carl-Daniel -- http://www.hailfinger.org/ ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <42029281.3070207-hi6Y0CQ0nG0@public.gmane.org>]
* Re: Radeon M7 and resuming from suspend-to-ram [not found] ` <42029281.3070207-hi6Y0CQ0nG0@public.gmane.org> @ 2005-02-03 22:53 ` Ralf Gerbig 2005-02-03 22:59 ` Carl-Daniel Hailfinger 1 sibling, 0 replies; 12+ messages in thread From: Ralf Gerbig @ 2005-02-03 22:53 UTC (permalink / raw) To: Carl-Daniel Hailfinger; +Cc: acpi-devel Moins, * Carl-Daniel Hailfinger: > Ralf Gerbig schrieb: >> Compiling the source I got: >> >> rge@lapdog2:/usr/src/vbetool-0.2> make >> if gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" >> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"vbetool\" >> -DVERSION=\"0.2\" -I. -I. >> -g -Wall -Werror -pedantic -g -O2 -MT vbetool.o -MD -MP -MF ".deps/vbetool.Tpo" \ >> -c -o vbetool.o `test -f 'vbetool.c' || echo './'`vbetool.c; \ >> then mv -f ".deps/vbetool.Tpo" ".deps/vbetool.Po"; \ >> else rm -f ".deps/vbetool.Tpo"; exit 1; \ >> fi >> In file included from /usr/include/stdlib.h:416, >> from vbetool.c:14: >> /usr/include/sys/types.h:62: error: conflicting types for `dev_t' >> /usr/include/linux/types.h:22: error: previous declaration of `dev_t' >> [...] > Yes, the pci.h shipped by SUSE has problems. Simply move the #include > <pci/pci.h> from the beginning to directly before #include <sys/kd.h> >> after fuzing around with -D, I temporally commented out the >> include. Thereafter adding -lpci to the end of the link command, I got >> a working executable. > This is a bug in Makefile.am. Pseudo-diff: > -AM_LDFLAGS = -lpci > +LIBS = -lpci > Then run aclocal, autoconf and automake again. yup, works with this diff: --- ../vbetool-0.2-orig/Makefile.am 2004-12-30 16:27:07.000000000 +0100 +++ Makefile.am 2005-02-03 23:38:08.000000000 +0100 @@ -12,4 +12,4 @@ $(RM) Makefile.in aclocal.m4 config.h.in stamp-h.in configure AM_CFLAGS = -g -Wall -Werror -pedantic -AM_LDFLAGS = -lpci +LIBS = -lpci --- ../vbetool-0.2-orig/vbetool.c 2004-12-31 16:11:19.000000000 +0100 +++ vbetool.c 2005-02-03 23:38:40.000000000 +0100 @@ -8,7 +8,6 @@ version 2 */ -#include <pci/pci.h> #include <assert.h> #include <stdio.h> #include <stdlib.h> @@ -17,6 +16,7 @@ #include <sys/ioctl.h> #include <sys/types.h> #include <sys/io.h> +#include <pci/pci.h> #include <sys/kd.h> #include <sys/stat.h> #include <errno.h> Ralf ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Radeon M7 and resuming from suspend-to-ram [not found] ` <42029281.3070207-hi6Y0CQ0nG0@public.gmane.org> 2005-02-03 22:53 ` Ralf Gerbig @ 2005-02-03 22:59 ` Carl-Daniel Hailfinger 1 sibling, 0 replies; 12+ messages in thread From: Carl-Daniel Hailfinger @ 2005-02-03 22:59 UTC (permalink / raw) To: Matthew Garrett; +Cc: acpi-devel [-- Attachment #1: Type: text/plain, Size: 1417 bytes --] Carl-Daniel Hailfinger schrieb: > Ralf Gerbig schrieb: > >>SuSE does not have a shared libpci, only static so the precompiled >>binary unsurprisingly did not work. >> >>Compiling the source I got: >> >>rge@lapdog2:/usr/src/vbetool-0.2> make >>if gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" >>-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"vbetool\" >>-DVERSION=\"0.2\" -I. -I. >>-g -Wall -Werror -pedantic -g -O2 -MT vbetool.o -MD -MP -MF ".deps/vbetool.Tpo" \ >> -c -o vbetool.o `test -f 'vbetool.c' || echo './'`vbetool.c; \ >>then mv -f ".deps/vbetool.Tpo" ".deps/vbetool.Po"; \ >>else rm -f ".deps/vbetool.Tpo"; exit 1; \ >>fi >>In file included from /usr/include/stdlib.h:416, >> from vbetool.c:14: >>/usr/include/sys/types.h:62: error: conflicting types for `dev_t' >>/usr/include/linux/types.h:22: error: previous declaration of `dev_t' >>[...] > > > Yes, the pci.h shipped by SUSE has problems. Simply move the #include > <pci/pci.h> from the beginning to directly before #include <sys/kd.h> > >>after fuzing around with -D, I temporally commented out the >>include. Thereafter adding -lpci to the end of the link command, I got >>a working executable. Matthew, could you apply attached patch and run aclocal, autoconf and automake again? This will fix the compile problems on SUSE 9.2. Regards, Carl-Daniel -- http://www.hailfinger.org/ [-- Attachment #2: vbetool-fix.diff --] [-- Type: text/x-patch, Size: 848 bytes --] diff -urN vbetool-0.2/Makefile.am vbetool-0.2-modified/Makefile.am --- vbetool-0.2/Makefile.am 2004-12-30 16:27:07.000000000 +0100 +++ vbetool-0.2-modified/Makefile.am 2005-02-03 21:58:16.000000000 +0100 @@ -12,4 +12,4 @@ $(RM) Makefile.in aclocal.m4 config.h.in stamp-h.in configure AM_CFLAGS = -g -Wall -Werror -pedantic -AM_LDFLAGS = -lpci +LIBS = -lpci diff -urN vbetool-0.2/vbetool.c vbetool-0.2-modified/vbetool.c --- vbetool-0.2/vbetool.c 2004-12-31 16:11:19.000000000 +0100 +++ vbetool-0.2-modified/vbetool.c 2005-02-03 22:02:53.000000000 +0100 @@ -8,7 +8,6 @@ version 2 */ -#include <pci/pci.h> #include <assert.h> #include <stdio.h> #include <stdlib.h> @@ -17,6 +16,7 @@ #include <sys/ioctl.h> #include <sys/types.h> #include <sys/io.h> +#include <pci/pci.h> #include <sys/kd.h> #include <sys/stat.h> #include <errno.h> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2005-02-03 22:59 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-14 14:12 Radeon M7 and resuming from suspend-to-ram Tomi Kallio
[not found] ` <41E7D334.6060003-y4dnIKzCb/d9YMlOZIriJw@public.gmane.org>
2005-01-14 15:26 ` Jeremy Moles
2005-01-14 20:06 ` Tomi Kallio
2005-01-14 16:24 ` Karol Kozimor
[not found] ` <20050114162359.GA22184-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
2005-01-14 19:53 ` Tomi Kallio
2005-01-14 17:31 ` Matthew Garrett
[not found] ` <1105723866.28126.10.camel-Xmbc1Sz64/5pghhO6/9/sx2eb7JE58TQ@public.gmane.org>
2005-01-18 22:11 ` Ralf Gerbig
[not found] ` <87k6qal75i.fsf-news-ihuhiKcgPLSELgA04lAiVw@public.gmane.org>
2005-01-19 0:46 ` Matthew Garrett
2005-01-19 20:07 ` Ralf Gerbig
[not found] ` <87ekghkwt0.fsf-news-ihuhiKcgPLSELgA04lAiVw@public.gmane.org>
2005-02-03 21:07 ` Carl-Daniel Hailfinger
[not found] ` <42029281.3070207-hi6Y0CQ0nG0@public.gmane.org>
2005-02-03 22:53 ` Ralf Gerbig
2005-02-03 22:59 ` Carl-Daniel Hailfinger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox