Is this still happening in 2.6.13-rc4?

Thanks.

Russell confirms that this is still happening in 2.6.13-rc4.

Not many changes in neofb, actually, just cleanups and addition of support for a
few chipsets, nothing radical.

The one change that may affect framebuffers is the disappearance of the
pm_register(pm_con,...) in vt.c.  Basically, consoles blank/unblank hooks are
also called on PM requests.

This change also got in in 2.6.12:

http://marc.theaimsgroup.com/?l=linux-kernel&m=111052009232499&w=2

Also, does the fact that neofb not have any suspend/resume hook matter with this
bug?

I'm currently working on a framebuffer driver that also fails on resume. Even
launching X failed to reinitialize the card.

apm, ouch.

Try commenting out device_suspend() and device_resume() calls from apm.c to see
if they are causing the problem

And also try to get ACPI suspend working...

I fixed the suspend/resume hooks of savagefb, and I was able to resume
successfully from standy and mem. I still can't resume from disk, but it's not
fb related because I tried it with vgacon also.

Anyway, I'll try to concoct a patch that adds suspend and resume for neofb.  I
don't have this hardware so let's see. 

Created attachment 5476 [details]
Add suspend/resume for neofb pci_driver

Can you try this patch?  It's a quick hack, compile tested only as I don't have
the hardware.

Created attachment 5477 [details]
Add suspend/resume for neofb pci_driver (2)

Oops, forgot to set the power state on resume.	Try this instead.

Just for the record, attached patch (id 5477) looks good to me. If it fixes the
problem, great and it should go to neofb maintainer.

Russel replied to me that the problem persists even if VGA is used.  So this is
not specific to the neofb driver, or to the framebuffer layer. I'm asking him to
check for "POST Video BIOS on Resume" in his BIOS setup, and to submit lspci -vvv
before and after resume.

I'm posting his reply:

	'Do you have an option to "POST Video BIOS on Resume" or
something like that in your BIOS setup?'
	No.

	'Also can you send the output of lspci -vvv before resume and
after resume?'
	I post the BEFORE, AFTER, and DIFF below.
	It does not change in kernel 2.6.11, but in 2.6.13 the status
line of the USB controller changed from:


< 	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-

to:

> > 	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-


(MAbort- to MAbort+), and the subsystem line on the Multimedia Audio
controller changed from:

< 	Subsystem: ESS Technology: Unknown device 8898

to:

> > 	Subsystem: IBM: Unknown device 0136

	Audio did not work on this particular episode of resume; it
usually does.


BEFORE:

00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
	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: 64
	Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 1.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3-
Rate=x1,x2
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (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=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 128
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: f4100000-f47fffff
	Prefetchable memory behind bridge: f5000000-f5ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B+

00:02.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
	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

00:02.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80
[Master])
	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: 64
	Region 4: I/O ports at 10c0 [size=16]

00:02.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00
[UHCI])
	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: 64
	Interrupt: pin D routed to IRQ 11
	Region 4: I/O ports at 1060 [size=32]

00:02.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
	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-
	Interrupt: pin ? routed to IRQ 9

00:03.0 CardBus bridge: Texas Instruments PCI1251B
	Subsystem: IBM: Unknown device 0138
	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: 168, cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at 14000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
	Memory window 0: 0c000000-0dfff000 (prefetchable)
	Memory window 1: 0e000000-0ffff000
	I/O window 0: 00002000-00002fff
	I/O window 1: 00003000-00003fff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

00:03.1 CardBus bridge: Texas Instruments PCI1251B
	Subsystem: IBM: Unknown device 0138
	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: 168, cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at 14001000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
	Memory window 0: 10000000-11fff000 (prefetchable)
	Memory window 1: 12000000-13fff000
	I/O window 0: 00004000-00004fff
	I/O window 1: 00005000-00005fff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

00:06.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)
	Subsystem: CIS Technology Inc Lucent Win Modem
	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-
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f4000000 (32-bit, non-prefetchable) [size=256]
	Region 1: I/O ports at 02e8 [size=8]
	Region 2: I/O ports at 1400 [size=256]
	Capabilities: [f8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 Multimedia audio controller: ESS Technology ES1969 Solo-1 Audiodrive
(rev 02)
	Subsystem: ESS Technology: Unknown device 8898
	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: 64 (500ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at 1080 [size=64]
	Region 1: I/O ports at 10e0 [size=16]
	Region 2: I/O ports at 10d0 [size=16]
	Region 3: I/O ports at 10fc [size=4]
	Region 4: I/O ports at 10f8 [size=4]
	Capabilities: [c0] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: Neomagic Corporation NM2200 [MagicGraph
256AV] (rev 20) (prog-if 00 [VGA])
	Subsystem: IBM: Unknown device 0137
	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: 128 (4000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f5000000 (32-bit, prefetchable) [size=16M]
	Region 1: Memory at f4400000 (32-bit, non-prefetchable) [size=4M]
	Region 2: Memory at f4100000 (32-bit, non-prefetchable) [size=1M]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-



AFTER:

00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
	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: 64
	Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [a0] AGP version 1.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3-
Rate=x1,x2
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (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=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 128
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: f4100000-f47fffff
	Prefetchable memory behind bridge: f5000000-f5ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B+

00:02.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
	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

00:02.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80
[Master])
	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: 64
	Region 4: I/O ports at 10c0 [size=16]

00:02.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00
[UHCI])
	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: 64
	Interrupt: pin D routed to IRQ 11
	Region 4: I/O ports at 1060 [size=32]

00:02.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
	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-
	Interrupt: pin ? routed to IRQ 9

00:03.0 CardBus bridge: Texas Instruments PCI1251B
	Subsystem: IBM: Unknown device 0138
	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: 168, cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at 14000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
	Memory window 0: 0c000000-0dfff000 (prefetchable)
	Memory window 1: 0e000000-0ffff000
	I/O window 0: 00002000-00002fff
	I/O window 1: 00003000-00003fff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

00:03.1 CardBus bridge: Texas Instruments PCI1251B
	Subsystem: IBM: Unknown device 0138
	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: 168, cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at 14001000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
	Memory window 0: 10000000-11fff000 (prefetchable)
	Memory window 1: 12000000-13fff000
	I/O window 0: 00004000-00004fff
	I/O window 1: 00005000-00005fff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

00:06.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)
	Subsystem: CIS Technology Inc Lucent Win Modem
	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-
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f4000000 (32-bit, non-prefetchable) [size=256]
	Region 1: I/O ports at 02e8 [size=8]
	Region 2: I/O ports at 1400 [size=256]
	Capabilities: [f8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 Multimedia audio controller: ESS Technology ES1969 Solo-1 Audiodrive
(rev 02)
	Subsystem: IBM: Unknown device 0136
	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: 64 (500ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at 1080 [size=64]
	Region 1: I/O ports at 10e0 [size=16]
	Region 2: I/O ports at 10d0 [size=16]
	Region 3: I/O ports at 10fc [size=4]
	Region 4: I/O ports at 10f8 [size=4]
	Capabilities: [c0] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: Neomagic Corporation NM2200 [MagicGraph
256AV] (rev 20) (prog-if 00 [VGA])
	Subsystem: IBM: Unknown device 0137
	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: 128 (4000ns min, 63750ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f5000000 (32-bit, prefetchable) [size=16M]
	Region 1: Memory at f4400000 (32-bit, non-prefetchable) [size=4M]
	Region 2: Memory at f4100000 (32-bit, non-prefetchable) [size=1M]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-


DIFF:

33c33
< 	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-
---
> > 	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
86c86
< 	Subsystem: IBM: Unknown device 0136
---
> > 	Subsystem: ESS Technology: Unknown device 8898

For those who have not kept up on the news, this bug has nothing to do with the
neofb driver:   it happens when I use VGA16 as well.

It definitely does not happen if I don't build the apm.ko module, but then
I don't get any suspension at all.  I commented out the device_suspend and
device_resume calls in apm.c but that made no difference.  I notice that
when I build apm.ko the compiler warns that pm_send_all is deprecated.  It
is now just a return in include/linux/pm.h.  Could this have something to do 
with it?

Hey, guys, I thought I delivered the news that the problem happens even
with the VGA driver, so it's not a neofb specific problem.

I used the apm.c from 2.6.11 (the last kernel on which this worked properly;
I have 2.6.14 installed also) and the problem still happened.

I tried to write an unblank routine.  I called unblank_screen, a routine
that vt.c exports, but it is in the kernel and the linker cannot link
to it.  How do I link to a routine in the kernel?

You can probably call setterm -powersave on. However, past kernels have a buggy
implementation of console blanking.  Someone did submit a patch a few days ago
that will fix this but I haven't tested it yet.  Wait for the next mm or rc
release if you want to test that this command works. 

Created attachment 6500 [details]
fix-console-blanking.patch

This is the patch to which Tony is referring.	Please test..

fix-console-blanking.patch made no difference.

setterm -powersave on  did not unblank the screen.

russell bell

If it works in 2.6.11 and is broken in 2.6.12, can you simply binary search for
the patch that breaks it? And... you are using apm, right?

I searched the 2.6.11 -> 2.6.12 patch file for everything that
used the word blank, suspend, or resume, restoring all the
2.6.11 code, and I have substituted the apm.c from 2.6.11.  
None have made a difference.  I have even commented out 
everything that refers to screen blanking.
Nothing has made a difference.

Yes, I use apm.  My old computer does not support acpi.

Well, git bisect is probably tool to use. There are good intros on the web...

Find a patch that repairs this in http://rickstewart.com/VTPatch

I had restored the portion with the unblank routine but not the
portion that calls it when trying to diagnose it myself.  The
patch works with some automatic relocation on 2.6.14.

Thanks, Pavel!

AYeee.... okay, this reintroduces old pm code. Not good, we want it removed.
Could you introduce platform_device and redo the same code, but using sysfs
infrastructure?

You can find simple user of plaftorm_device code in arch/arm/common/locomo.c ...

Created attachment 6683 [details]
Convert to platform device, add suspend/resume hooks

Pavel is right, that's legacy code.

Try this patch instead.  It converts vgacon to a platform_device (which
basically
does nothing in its probe functions because vgacon is initialized directly by
early console init), but it adds suspend/resume hooks.

Tested in my system with echo {standby, mem, disk} > /sys/power/state .

With what version of the kernel must I use this patch?  I upgraded to
2.6.15-rc2, the latest on the site, and the patch is inappropriate.
The first and third hunks worked by relocating themselves.  The second
hunk I tried to put in by hand since it is just one line, just before
'return display_desc', but that caused an immediate crash on boot.
Then I noticed that the 'cue' for the second hunk refers to some
constants absent from 2.6.15-rc2, thus I need stuff outside vgacon.c
to make this patch work.

I use the mm tree.  Get it here,
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc2/2.6.15-rc2-mm1/2.6.15-rc2-mm1.bz2,
apply it on top of linux-2.6.15-rc2, then my patch.

I did as you instructed.  The second hunk of your patch still fails.
I put it in by hand (the 'vga_init = 1' before 'return display_desc' 
and my system crashes on boot.

Strange. I just tried the patch on linux-2.6.15-rc2-mm1 and it applied, albeit
with a single offset.  I also recompiled my kernel to support apm instead of
acpi.  I did not experience any crash but my system did not finish booting, and
I have to do a hard reset. But that's with and without the patch.

Can you describe what the crash is? Any oops, display corruption, etc?

Anyway, can you also post your .config?

Tony

A build from the unpatched 2.6.15-rc2-mm source works for me.
Your patch works automatically if I set the fuzz to 3.
When I boot with it, the screen blanks after 
'BIOS data check successful' and makes no further
progress.  The logs record nothing of the boot.

I have backed out the patch, built the unpatched kernel
again, confirmed that it worked, then installed the patch
again to confirm that it fails.

You can find my .config at http://rickstewart.com/config

Can you boot with video=neofb:off?

'Can you boot with video=neofb:off?'

No.  The same thing happens.

Created attachment 6714 [details]
Dummy con on startup

Getting stranger...

Can you try this patch?  This patch will force your initial console to dummycon
and then you'll have vgacon only when vgacon_probe get's called.

It's only a test patch so we can localize where the hang occurs. If you
complete the boot process, test if suspend/resume works for you.

'Can you try this patch?  This patch will force your initial console to dummycon
and then you'll have vgacon only when vgacon_probe get's called.'
This crashes in the same manner.

If you give me an idea of what you are trying to do then I can try things on
my own.  I can program but I have not hacked the Linux kernel.  Is there some
way to put in code to report progress, at least on the screen?  Is the BIOS
still usable?  I wrote in assembler for years, systems software, not that
I was a star, but I could track problems with output to the screen through
the BIOS before the OS loaded.

Created attachment 6717 [details]
Add suspend/resume for vgacon

Forget the previous patches.  I think I was able to duplicate the hang when I
have a vga= in my option parameter.  The previous patch conflicts with vesafb.

Try this patch.

> If you give me an idea of what you are trying to do then I can try things on
> my own.  I can program but I have not hacked the Linux kernel.  Is there some
> way to put in code to report progress, at least on the screen?  Is the BIOS
> still usable?  I wrote in assembler for years, systems software, not that
> I was a star, but I could track problems with output to the screen through
> the BIOS before the OS loaded.

The main problem is that the vgacon driver is not hooked up to power management.
 Another difficulty is that vgacon is unusual in that it has to be active very,
very early during the boot process. Which means that it doesn't go through the
kernel's standard initcalls. So with this patch, we let vgacon initialize when
vgacon_startup() is directly called by con_init() in vt.c.  Since this is very
early, we cannot setup the suspend/hooks yet.  Later on, we do hookup to power
management when vgacon_start() is called by module_init().

Another difficulty is that vgacon_startup can fail (ie, if vesafb is active), so
we flag that with vga_init.

Russell, does the patch from comment 31 fix the problem for you?

No.  I must have forgotten to post that response.  I tried almost
immediately.

 

If you can use acpi, try booting with

acpi_sleep=s3_bios,s3_mode

If not, try this script:

vbetool vbestate save > /tmp/vbestate
/* suspend here */
vbetool post
sleep 1
vbetool vbestate restore < /tmp/vbestate

ACPI will put the machine (a new machine:  the
old machine did not support ACPI) to sleep with
mode 3 but I have found nothing to wake it up.
What is supposed to?  The keyboard is ignored
but the log files record activity during the
sleep period, so I know it's on.

If you see periodic log entries, machine is not really sleeping. Power button
should be enough to wake the machine up, but your machine is probably not sleeping.

Try c-a-d to see if it reboots. Ouch and open new bugreport if this is different
machine (and different problem).

This bug is reported for 2.6.12 --- that's really historic. If it still happens
with new kernel, please open new report.

This still happens in 2.6.16.16.




 

Okay, so some variant of 

@@ -3209,6 +3218,24 @@ void vcs_scr_writew(struct vc_data *vc, 
 	}
 }
 
+static int pm_con_request(struct pm_dev *dev, pm_request_t rqst, void *data)
+{
+	switch (rqst)
+	{
+	case PM_RESUME:
+		acquire_console_sem();
+		unblank_screen();
+		release_console_sem();
+		break;
+	case PM_SUSPEND:
+		acquire_console_sem();
+		do_blank_screen(0);
+		release_console_sem();
+		break;
+	}
+	return 0;
+}

...fixes it for you. Try to find variant that is acceptable with new kernel --
looks like Antonio has some ideas. Or just hardcode 

+		acquire_console_sem();
+		unblank_screen();
+		release_console_sem();

...into the right place into APM. If that works for you, it may even be
acceptable. (Original hook is in vt subsystem, and hooking vt subsystem is not
really going to be simple. Plus we only want that in apm case).

Ping? Did this get somehow solved for 2.6.18?

Sorry!  My new machine does not support APM.  The one that exhibits this
symptom I lent out.  I will have to fetch it back to test it.  I have not
yet.

Ok, if we can't reproduce it, lets close it for now. Reopen if still present.