[mhf@mhfl2 13:40:27 mhf]$ cat /proc/interrupts
CPU0
0: 1242348 XT-PIC timer
1: 5253 XT-PIC i8042
2: 0 XT-PIC cascade
5: 88 XT-PIC Toshiba America Info ToPIC95 PCI to Cardb, serial
8: 0 XT-PIC rtc
9: 162 XT-PIC acpi
10: 1003 XT-PIC eth0
12: 23967 XT-PIC i8042
14: 8698 XT-PIC ide0
NMI: 0
LOC: 0
ERR: 5
MIS: 0
lspci shows that IRQ level: byte 3C is FF, it should be 5
00:12.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support (rev 32)
00: 79 11 17 06 00 00 90 04 32 00 07 06 00 40 82 00
10: 00 10 00 10 80 00 80 04 00 01 04 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 01 00 00
40: 79 11 01 00 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
When this value is used by pci_restore_state, interrupt
obviously dies.
Dunno if this is hardware readback fault or driver issue.
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
Hi!
> [mhf@mhfl2 13:40:27 mhf]$ cat /proc/interrupts
> CPU0
> 0: 1242348 XT-PIC timer
> 1: 5253 XT-PIC i8042
> 2: 0 XT-PIC cascade
> 5: 88 XT-PIC Toshiba America Info ToPIC95 PCI to Cardb, serial
> 8: 0 XT-PIC rtc
> 9: 162 XT-PIC acpi
> 10: 1003 XT-PIC eth0
> 12: 23967 XT-PIC i8042
> 14: 8698 XT-PIC ide0
> NMI: 0
> LOC: 0
> ERR: 5
> MIS: 0
>
>
> lspci shows that IRQ level: byte 3C is FF, it should be 5
>
> 00:12.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support (rev 32)
> 00: 79 11 17 06 00 00 90 04 32 00 07 06 00 40 82 00
> 10: 00 10 00 10 80 00 80 04 00 01 04 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 01 00 00
> 40: 79 11 01 00 01 00 00 00 00 00 00 00 00 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> When this value is used by pci_restore_state, interrupt
> obviously dies.
>
> Dunno if this is hardware readback fault or driver issue.
In any case it should be easy to fixup in ToPIC95 driver...
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
On Monday 14 July 2003 13:41, Michael Frank wrote:
>
> Dunno if this is hardware readback fault or driver issue.
>
Very funny - suspend/resume is not implemented ;)
static int yenta_suspend(struct pcmcia_socket *sock)
{
struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
yenta_set_socket(sock, &dead_socket);
/* Disable interrupts */
cb_writel(socket, CB_SOCKET_MASK, 0x0);
/*
* This does not work currently. The controller
* loses too much information during D3 to come up
* cleanly. We should probably fix yenta_init()
* to update all the critical registers, notably
* the IO and MEM bridging region data.. That is
* something that pci_set_power_state() should
* probably know about bridges anyway.
*
pci_set_power_state(socket->dev, 3);
*/
return 0;
}
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
On Mon, Jul 14, 2003 at 05:28:24PM +0800, Michael Frank wrote:
> Very funny - suspend/resume is not implemented ;)
It hasn't been implemented properly for a long long time.
I think I have all the bits necessary, but need testers willing to
try stuff out. I'll produce a patch in the next couple of days.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Monday 14 July 2003 19:01, Russell King wrote:
> On Mon, Jul 14, 2003 at 05:28:24PM +0800, Michael Frank wrote:
> > Very funny - suspend/resume is not implemented ;)
>
> It hasn't been implemented properly for a long long time.
>
> I think I have all the bits necessary, but need testers willing to
> try stuff out. I'll produce a patch in the next couple of days.
Thank you, I look forward to testing it.
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
On Mon, Jul 14, 2003 at 07:37:29PM +0800, Michael Frank wrote:
> On Monday 14 July 2003 19:01, Russell King wrote:
> > On Mon, Jul 14, 2003 at 05:28:24PM +0800, Michael Frank wrote:
> > > Very funny - suspend/resume is not implemented ;)
> >
> > It hasn't been implemented properly for a long long time.
> >
> > I think I have all the bits necessary, but need testers willing to
> > try stuff out. I'll produce a patch in the next couple of days.
>
> Thank you, I look forward to testing it.
Ok, this is a rudimentary insertion of the pci_save_state/pci_restore_state
calls into yenta_socket.c. This should result in the first 64 bytes
of config space being saved and restored over suspend/resume cycles.
diff -u /net/flint/usrc/linux-bk-2.5/linux-2.5-pcmcia/drivers/pcmcia/yenta_socket.c linux/drivers/pcmcia/yenta_socket.c
--- /net/flint/usrc/linux-bk-2.5/linux-2.5-pcmcia/drivers/pcmcia/yenta_socket.c Sun Mar 23 11:57:21 2003
+++ linux/drivers/pcmcia/yenta_socket.c Fri Mar 28 23:17:12 2003
@@ -534,8 +534,6 @@
u16 bridge;
struct pci_dev *dev = socket->dev;
- pci_set_power_state(socket->dev, 0);
-
config_writel(socket, CB_LEGACY_MODE_BASE, 0);
config_writel(socket, PCI_BASE_ADDRESS_0, dev->resource[0].start);
config_writew(socket, PCI_COMMAND,
@@ -577,6 +575,10 @@
static int yenta_init(struct pcmcia_socket *sock)
{
struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
+
+ pci_set_power_state(socket->dev, 0);
+ pci_restore_state(socket->dev, socket->saved_state);
+
yenta_config_init(socket);
yenta_clear_maps(socket);
@@ -594,6 +596,8 @@
/* Disable interrupts */
cb_writel(socket, CB_SOCKET_MASK, 0x0);
+ pci_save_state(socket->dev, socket->saved_state);
+
/*
* This does not work currently. The controller
* loses too much information during D3 to come up
@@ -635,7 +639,7 @@
if (type & IORESOURCE_IO)
mask = ~3;
- offset = 0x1c + 8*nr;
+ offset = PCI_CB_MEMORY_BASE_0 + 8*nr;
bus = socket->dev->subordinate;
res = socket->dev->resource + PCI_BRIDGE_RESOURCES + nr;
res->name = bus->name;
@@ -862,6 +866,8 @@
/* Set up the bridge regions.. */
yenta_allocate_resources(socket);
+
+ pci_save_state(dev, socket->saved_state);
socket->cb_irq = dev->irq;
diff -u /net/flint/usrc/linux-bk-2.5/linux-2.5-pcmcia/drivers/pcmcia/yenta_socket.h linux/drivers/pcmcia/yenta_socket.h
--- /net/flint/usrc/linux-bk-2.5/linux-2.5-pcmcia/drivers/pcmcia/yenta_socket.h Sun Mar 23 11:57:20 2003
+++ linux/drivers/pcmcia/yenta_socket.h Fri Mar 28 23:13:33 2003
@@ -105,6 +105,9 @@
/* A few words of private data for special stuff of overrides... */
unsigned int private[8];
+
+ /* PCI saved state - 64 bytes */
+ u32 saved_state[16];
};
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, Jul 14, 2003 at 03:50:51PM +0100, Russell King wrote:
> yenta_allocate_resources(socket);
> +
> + pci_save_state(dev, socket->saved_state);
>
> socket->cb_irq = dev->irq;
>
This reminds me, PCI Express makes the PCI config area larger, going
from 256 bytes to either 4K or 64K IIRC.
I wonder if we want new pci_{save,restore}_xstate functions?
Or change the pci_{save,restore}_state API now to work with larger
config areas?
Intel probably has some patches internally for this, I bet.
Jeff
On Mon, Jul 14, 2003 at 11:04:35AM -0400, Jeff Garzik wrote:
> On Mon, Jul 14, 2003 at 03:50:51PM +0100, Russell King wrote:
> > yenta_allocate_resources(socket);
> > +
> > + pci_save_state(dev, socket->saved_state);
> >
> > socket->cb_irq = dev->irq;
> >
>
> This reminds me, PCI Express makes the PCI config area larger, going
> from 256 bytes to either 4K or 64K IIRC.
>
> I wonder if we want new pci_{save,restore}_xstate functions?
> Or change the pci_{save,restore}_state API now to work with larger
> config areas?
Maybe we really want an API where you can pass in the size of your
buffer (which also determines how much gets saved) ?
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, Jul 14, 2003 at 11:18:07PM +0800, Michael Frank wrote:
> Right, using the dword write function for 16 words or so is OK, but
> rather clumsy for much more than that.
It's config space, that's as good as it gets.
(The last PCI spec I read didn't allow burst accesses to config space,
and it isn't supposed to be a "memory like" space.)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Monday 14 July 2003 23:21, Russell King wrote:
> On Mon, Jul 14, 2003 at 11:04:35AM -0400, Jeff Garzik wrote:
> > On Mon, Jul 14, 2003 at 03:50:51PM +0100, Russell King wrote:
I'll give that patch a go tomorrow.
> > > yenta_allocate_resources(socket);
> > > +
> > > + pci_save_state(dev, socket->saved_state);
> > >
> > > socket->cb_irq = dev->irq;
> >
> > This reminds me, PCI Express makes the PCI config area larger, going
> > from 256 bytes to either 4K or 64K IIRC.
> >
> > I wonder if we want new pci_{save,restore}_xstate functions?
> > Or change the pci_{save,restore}_state API now to work with larger
> > config areas?
>
> Maybe we really want an API where you can pass in the size of your
> buffer (which also determines how much gets saved) ?
Right, using the dword write function for 16 words or so is OK, but
rather clumsy for much more than that.
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
On Monday 14 July 2003 23:34, Russell King wrote:
> On Mon, Jul 14, 2003 at 11:18:07PM +0800, Michael Frank wrote:
> > Right, using the dword write function for 16 words or so is OK, but
> > rather clumsy for much more than that.
>
> It's config space, that's as good as it gets.
>
> (The last PCI spec I read didn't allow burst accesses to config space,
> and it isn't supposed to be a "memory like" space.)
Time for me to find and read the PCI spec and the PCMCIA spec...
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
On Monday 14 July 2003 22:50, Russell King wrote:
> On Mon, Jul 14, 2003 at 07:37:29PM +0800, Michael Frank wrote:
> > On Monday 14 July 2003 19:01, Russell King wrote:
> > > On Mon, Jul 14, 2003 at 05:28:24PM +0800, Michael Frank wrote:
> > > > Very funny - suspend/resume is not implemented ;)
> > >
> > > It hasn't been implemented properly for a long long time.
> > >
> > > I think I have all the bits necessary, but need testers willing to
> > > try stuff out. I'll produce a patch in the next couple of days.
> >
> > Thank you, I look forward to testing it.
>
> Ok, this is a rudimentary insertion of the pci_save_state/pci_restore_state
> calls into yenta_socket.c. This should result in the first 64 bytes
> of config space being saved and restored over suspend/resume cycles.
>
Applied to 2.5.75-mm1 + test patch below which also prints pci irq @0x3c
problems seen:
- yenta_probe pci_save_state saves irq as ff. Moved to end of function, result same
- both swsusp and ACPI/S3 do _not_ call yenta_suspend and yenta_init, so it still
wont work
Test Patch:
diff -uN drivers/pcmcia/yenta_socket.c.orig drivers/pcmcia/yenta_socket.c
--- drivers/pcmcia/yenta_socket.c.orig 2003-07-15 12:39:52.000000000 +0800
+++ drivers/pcmcia/yenta_socket.c 2003-07-15 13:17:39.000000000 +0800
@@ -577,7 +577,9 @@
struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
pci_set_power_state(socket->dev, 0);
- pci_restore_state(socket->dev, socket->saved_state);
+ printk("Yenta: init restore state %x\n",(u8)socket->saved_state[0xf]);
+
+ pci_restore_state(socket->dev, socket->saved_state);
yenta_config_init(socket);
yenta_clear_maps(socket);
@@ -596,6 +598,7 @@
/* Disable interrupts */
cb_writel(socket, CB_SOCKET_MASK, 0x0);
+ printk("Yenta: suspend save state %x\n",(u8)socket->saved_state[0xf]);
pci_save_state(socket->dev, socket->saved_state);
/*
@@ -867,8 +870,6 @@
/* Set up the bridge regions.. */
yenta_allocate_resources(socket);
- pci_save_state(dev, socket->saved_state);
-
socket->cb_irq = dev->irq;
/* Do we have special options for the device? */
@@ -897,6 +898,10 @@
/* Figure out what the dang thing can do for the PCMCIA layer... */
yenta_get_socket_capabilities(socket, isa_interrupts);
printk("Socket status: %08x\n", cb_readl(socket, CB_SOCKET_STATE));
+ pci_save_state(dev, socket->saved_state);
+ printk("Yenta: probe saved state %x\n",(u8)socket->saved_state[0xf]);
+ (u8)socket->saved_state[0xf] = socket->cb_irq;
+ printk("Yenta: probe saved state irq fixed %x\n",(u8)socket->saved_state[0xf]);
/* Register it with the pcmcia layer.. */
return pcmcia_register_socket(&socket->socket);
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
This one fixes the order of printing the state info in yenta_suspend
diff -uN drivers/pcmcia/yenta_socket.c.orig drivers/pcmcia/yenta_socket.c
--- drivers/pcmcia/yenta_socket.c.orig 2003-07-15 12:39:52.000000000 +0800
+++ drivers/pcmcia/yenta_socket.c 2003-07-15 14:22:28.000000000 +0800
@@ -577,7 +577,9 @@
struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
pci_set_power_state(socket->dev, 0);
- pci_restore_state(socket->dev, socket->saved_state);
+
+ pci_restore_state(socket->dev, socket->saved_state);
+ printk("Yenta: init restored state %x\n",(u8)socket->saved_state[0xf]);
yenta_config_init(socket);
yenta_clear_maps(socket);
@@ -597,6 +599,7 @@
cb_writel(socket, CB_SOCKET_MASK, 0x0);
pci_save_state(socket->dev, socket->saved_state);
+ printk("Yenta: suspend saved state %x\n",(u8)socket->saved_state[0xf]);
/*
* This does not work currently. The controller
@@ -867,8 +870,6 @@
/* Set up the bridge regions.. */
yenta_allocate_resources(socket);
- pci_save_state(dev, socket->saved_state);
-
socket->cb_irq = dev->irq;
/* Do we have special options for the device? */
@@ -897,6 +898,10 @@
/* Figure out what the dang thing can do for the PCMCIA layer... */
yenta_get_socket_capabilities(socket, isa_interrupts);
printk("Socket status: %08x\n", cb_readl(socket, CB_SOCKET_STATE));
+ pci_save_state(dev, socket->saved_state);
+ printk("Yenta: probe saved state %x\n",(u8)socket->saved_state[0xf]);
+ (u8)socket->saved_state[0xf] = socket->cb_irq;
+ printk("Yenta: probe saved state irq fixed %x\n",(u8)socket->saved_state[0xf]);
/* Register it with the pcmcia layer.. */
return pcmcia_register_socket(&socket->socket);
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
On Tue, Jul 15, 2003 at 01:31:37PM +0800, Michael Frank wrote:
> problems seen:
>
> - yenta_probe pci_save_state saves irq as ff. Moved to end of function, result same
irq was 0xff at boot, so it is neither here nor there whether it remains
0xff after a resume. If it works at boot with 0xff, it should work after
a resume with 0xff.
> - both swsusp and ACPI/S3 do _not_ call yenta_suspend and yenta_init,
> so it still wont work
Please confirm whether pcmcia_socket_dev_suspend() is called from
yenta.c with SUSPEND_SAVE_STATE and not zero. (it should be
SUSPEND_SAVE_STATE.)
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Tuesday 15 July 2003 15:56, Russell King wrote:
> On Tue, Jul 15, 2003 at 01:31:37PM +0800, Michael Frank wrote:
> > problems seen:
> >
> > - yenta_probe pci_save_state saves irq as ff. Moved to end of function,
> > result same
>
> irq was 0xff at boot, so it is neither here nor there whether it remains
> 0xff after a resume. If it works at boot with 0xff, it should work after
> a resume with 0xff.
>
> > - both swsusp and ACPI/S3 do _not_ call yenta_suspend and yenta_init,
> > so it still wont work
>
> Please confirm whether pcmcia_socket_dev_suspend() is called from
> yenta.c with SUSPEND_SAVE_STATE and not zero. (it should be
> SUSPEND_SAVE_STATE.)
Fixed that. Now it calls suspend and resume. It still doesn't work ;)
I believe it is not here now, we need to look elsewhere, as interrupts
stay dead also after reloading modules (see logs).
For this test:
$ lsmod
Module Size Used by
8250_cs 7428 0
ds 11136 3 8250_cs
yenta_socket 11008 1
pcmcia_core 59904 3 8250_cs,ds,yenta_socket
toshiba_acpi 5268 0
swsusp
Jul 15 17:04:58 mhfl2 kernel: Stopping tasks: klogd entered refrigerator
Jul 15 17:04:58 mhfl2 kernel: =init entered refrigerator
snip
Jul 15 17:04:59 mhfl2 kernel: =kjournald entered refrigerator
Jul 15 17:04:59 mhfl2 kernel: =|
Jul 15 17:04:59 mhfl2 kernel: Freeing memory: .......|
Jul 15 17:04:59 mhfl2 kernel: Syncing disks before copy
Jul 15 17:05:00 mhfl2 kernel: Suspending devices
Jul 15 17:05:00 mhfl2 kernel: Suspending devices
Jul 15 17:05:00 mhfl2 kernel: hda: start_power_step(step: 0)
Jul 15 17:05:00 mhfl2 kernel: hda: completing PM request, suspend
Jul 15 17:05:00 mhfl2 kernel: Suspending devices
Jul 15 17:05:00 mhfl2 kernel: Yenta: dev suspend
Jul 15 17:05:00 mhfl2 kernel: Yenta: suspend saved state ff
Jul 15 17:05:00 mhfl2 kernel: /critical section: Counting pages to copy[nosave c03e2000] (pages needed: 3426+512=3938 free: 57849)
Jul 15 17:05:00 mhfl2 kernel: Alloc pagedir
Jul 15 17:05:00 mhfl2 kernel: ....[nosave c03e2000]Enabling SEP on CPU 0
Jul 15 17:05:00 mhfl2 kernel: Freeing prev allocated pagedir
power down - resume
Jul 15 17:05:00 mhfl2 kernel: Yenta: dev resume
Jul 15 17:05:00 mhfl2 kernel: Yenta: init restored state ff
Jul 15 17:05:00 mhfl2 kernel: Trying to free nonexistent resource <000003f8-000003ff>
Jul 15 17:05:00 mhfl2 kernel: Yenta: init restored state ff
Jul 15 17:05:00 mhfl2 kernel: hda: Wakeup request inited, waiting for !BSY...
Jul 15 17:05:00 mhfl2 kernel: hda: start_power_step(step: 1000)
Jul 15 17:05:00 mhfl2 kernel: hda: completing PM request, resume
Jul 15 17:05:01 mhfl2 kernel: Devices Resumed
Jul 15 17:05:01 mhfl2 kernel: Devices Resumed
Jul 15 17:05:01 mhfl2 kernel: Yenta: dev resume
Jul 15 17:05:01 mhfl2 kernel: Fixing swap signatures... ok
Jul 15 17:05:01 mhfl2 kernel: Restarting processes...
Jul 15 17:05:01 mhfl2 kernel: Restarting tasks... done
Jul 15 17:05:01 mhfl2 kernel: init left refrigerator
Jul 15 17:05:01 mhfl2 kernel: pdflush left refrigerator
snip
Resumed: no interrupts
stop pcmcia
Jul 15 17:05:02 mhfl2 cardmgr[774]: executing: './serial stop ttyS0'
removing all pcmcia modules
Jul 15 17:05:40 mhfl2 su(pam_unix)[855]: session opened for user root by mhf(uid=500)
Jul 15 17:05:50 mhfl2 cardmgr[774]: exiting
Jul 15 17:06:28 mhfl2 kernel: unloading Kernel Card Services
start pcmcia again
Jul 15 17:06:42 mhfl2 kernel: Linux Kernel Card Services 3.1.22
Jul 15 17:06:42 mhfl2 kernel: options: [pci] [cardbus] [pm]
Jul 15 17:06:43 mhfl2 kernel: Intel PCIC probe: not found.
Jul 15 17:06:43 mhfl2 kernel: Yenta IRQ list 0000, PCI irq5
Jul 15 17:06:43 mhfl2 kernel: Socket status: ffffffff
Jul 15 17:06:43 mhfl2 kernel: Yenta: probe saved state ff
Jul 15 17:06:43 mhfl2 kernel: Yenta: init restored state ff
Jul 15 17:06:43 mhfl2 cardmgr[996]: watching 1 sockets
Jul 15 17:06:43 mhfl2 kernel: cs: IO port probe 0x0c00-0x0cff: clean.
Jul 15 17:06:43 mhfl2 kernel: cs: IO port probe 0x0800-0x08ff: clean.
Jul 15 17:06:43 mhfl2 kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x1e0-0x1e7 0x3c0-0x3df 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7
Jul 15 17:06:43 mhfl2 kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Jul 15 17:06:43 mhfl2 cardmgr[997]: starting, version is 3.2.4
interrupts still dead, now it is something else!
reboot (need to use modem for this email ;)
Jul 15 17:07:53 mhfl2 shutdown: shutting down for system reboot
diff -uN drivers/pcmcia/yenta_socket.c.orig drivers/pcmcia/yenta_socket.c
--- drivers/pcmcia/yenta_socket.c.orig 2003-07-15 12:39:52.000000000 +0800
+++ drivers/pcmcia/yenta_socket.c 2003-07-15 17:19:11.000000000 +0800
@@ -577,7 +577,9 @@
struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
pci_set_power_state(socket->dev, 0);
- pci_restore_state(socket->dev, socket->saved_state);
+
+ pci_restore_state(socket->dev, socket->saved_state);
+ printk("Yenta: init restored state %x\n",(u8)socket->saved_state[0xf]);
yenta_config_init(socket);
yenta_clear_maps(socket);
@@ -597,6 +599,7 @@
cb_writel(socket, CB_SOCKET_MASK, 0x0);
pci_save_state(socket->dev, socket->saved_state);
+ printk("Yenta: suspend saved state %x\n",(u8)socket->saved_state[0xf]);
/*
* This does not work currently. The controller
@@ -867,8 +870,6 @@
/* Set up the bridge regions.. */
yenta_allocate_resources(socket);
- pci_save_state(dev, socket->saved_state);
-
socket->cb_irq = dev->irq;
/* Do we have special options for the device? */
@@ -897,6 +898,10 @@
/* Figure out what the dang thing can do for the PCMCIA layer... */
yenta_get_socket_capabilities(socket, isa_interrupts);
printk("Socket status: %08x\n", cb_readl(socket, CB_SOCKET_STATE));
+ pci_save_state(dev, socket->saved_state);
+ printk("Yenta: probe saved state %x\n",(u8)socket->saved_state[0xf]);
+ //(u8)socket->saved_state[0xf] = socket->cb_irq;
+ //printk("Yenta: probe saved state irq fixed %x\n",(u8)socket->saved_state[0xf]);
/* Register it with the pcmcia layer.. */
return pcmcia_register_socket(&socket->socket);
@@ -905,12 +910,14 @@
static int yenta_dev_suspend (struct pci_dev *dev, u32 state)
{
- return pcmcia_socket_dev_suspend(&dev->dev, state, 0);
+ printk("Yenta: dev suspend\n");
+ return pcmcia_socket_dev_suspend(&dev->dev, state, SUSPEND_SAVE_STATE);
}
static int yenta_dev_resume (struct pci_dev *dev)
{
+ printk("Yenta: dev resume\n");
return pcmcia_socket_dev_resume(&dev->dev, RESUME_RESTORE_STATE);
}
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
I'll try to trace where the interrupt dies.
I tried already an int 0x25 in yenta_init which has no effect...
BTW:
On Tuesday 15 July 2003 17:34, Michael Frank wrote:
> Jul 15 17:05:00 mhfl2 kernel: Suspending devices
> Jul 15 17:05:00 mhfl2 kernel: Yenta: dev suspend
> Jul 15 17:05:00 mhfl2 kernel: Yenta: suspend saved state ff
> Jul 15 17:05:00 mhfl2 kernel: /critical section: Counting pages to
> copy[nosave c03e2000] (pages needed: 3426+512=3938 free: 57849) Jul 15
> 17:05:00 mhfl2 kernel: Alloc pagedir
> Jul 15 17:05:00 mhfl2 kernel: ....[nosave c03e2000]Enabling SEP on CPU 0
> Jul 15 17:05:00 mhfl2 kernel: Freeing prev allocated pagedir
>
> power down - resume
>
> Jul 15 17:05:00 mhfl2 kernel: Yenta: dev resume
Dev resume ahead of socket resume?
> Jul 15 17:05:00 mhfl2 kernel: Yenta: init restored state ff
> Jul 15 17:05:00 mhfl2 kernel: Trying to free nonexistent resource
> <000003f8-000003ff> Jul 15 17:05:00 mhfl2 kernel: Yenta: init restored
> state ff
> Jul 15 17:05:00 mhfl2 kernel: hda: Wakeup request inited, waiting for
> !BSY... Jul 15 17:05:00 mhfl2 kernel: hda: start_power_step(step: 1000)
> Jul 15 17:05:00 mhfl2 kernel: hda: completing PM request, resume
> Jul 15 17:05:01 mhfl2 kernel: Devices Resumed
> Jul 15 17:05:01 mhfl2 kernel: Devices Resumed
> Jul 15 17:05:01 mhfl2 kernel: Yenta: dev resume
One more dev resume
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
On Tue, Jul 15, 2003 at 06:42:17PM +0800, Michael Frank wrote:
> On Tuesday 15 July 2003 17:34, Michael Frank wrote:
> > Jul 15 17:05:00 mhfl2 kernel: Suspending devices
> > Jul 15 17:05:00 mhfl2 kernel: Yenta: dev suspend
> > Jul 15 17:05:00 mhfl2 kernel: Yenta: suspend saved state ff
> > Jul 15 17:05:00 mhfl2 kernel: /critical section: Counting pages to
> > copy[nosave c03e2000] (pages needed: 3426+512=3938 free: 57849) Jul 15
> > 17:05:00 mhfl2 kernel: Alloc pagedir
> > Jul 15 17:05:00 mhfl2 kernel: ....[nosave c03e2000]Enabling SEP on CPU 0
> > Jul 15 17:05:00 mhfl2 kernel: Freeing prev allocated pagedir
> >
> > power down - resume
> >
> > Jul 15 17:05:00 mhfl2 kernel: Yenta: dev resume
>
> Dev resume ahead of socket resume?
Yes, the dev resume triggers the per-socket resume.
> > Jul 15 17:05:00 mhfl2 kernel: Yenta: init restored state ff
> > Jul 15 17:05:00 mhfl2 kernel: Trying to free nonexistent resource
> > <000003f8-000003ff> Jul 15 17:05:00 mhfl2 kernel: Yenta: init restored
> > state ff
> > Jul 15 17:05:00 mhfl2 kernel: hda: Wakeup request inited, waiting for
> > !BSY... Jul 15 17:05:00 mhfl2 kernel: hda: start_power_step(step: 1000)
> > Jul 15 17:05:00 mhfl2 kernel: hda: completing PM request, resume
> > Jul 15 17:05:01 mhfl2 kernel: Devices Resumed
> > Jul 15 17:05:01 mhfl2 kernel: Devices Resumed
> > Jul 15 17:05:01 mhfl2 kernel: Yenta: dev resume
>
> One more dev resume
The extra resume is caused by not having all the PM information available
to PCI device drivers. This is probably another bit of the PM interface
which needs to be fixed for 2.6.0.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Tuesday 15 July 2003 17:34, Michael Frank wrote:
> I believe it is not here now, we need to look elsewhere, as interrupts
> stay dead also after reloading modules (see logs).
>
> Jul 15 17:06:43 mhfl2 kernel: Socket status: ffffffff
FFFFFFFF!!!!
This returns ffffffff too:
cb_writel(socket, CB_SOCKET_MASK, 0x0);
if ((temp = cb_readl(socket, CB_SOCKET_MASK)) != 0)
printk("Yenta: probe can't write socket mask %x\n",temp);
because the device is somewhat "passive" after a suspend....
Should we save all registers? - it has 128
It sits on the same bus with ide, e100 which work, so it won't
be pci related - OK?.
Another thing, even lspci returns crap after suspend because
data come from RAM rather than device(s).
I would like to do generic pci_save_state/pci_restore_state
centraly in the pci driver. It would reduce other driver side
work too.
What is the possible downside of this approach and your
opinion in general?
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
On Wednesday 16 July 2003 00:09, Michael Frank wrote:
> Should we save all registers? - it has 128
Did that, no effect, the controller remains inaccessible
>
> It sits on the same bus with ide, e100 which work, so it won't
> be pci related - OK?.
Tested the driver by unloading/reloading it several times.
Before resume OK. After resume the controller is inaccessible as if "removed"
What other state info could have been lost?
Others: There is no matching kfree for the kmalloc of the socket
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/
With ACPI=off and state saving and powering the device down with
pci_set_power_state on suspend, it is functional on resume but
for the IRQ allocation. IRQ is set to 0 and card events work.
Getting on with ACPI then and expect this to take a while...
Others: pci=biosirq generates endless oopses/segfaults on boot
(no serial console to grab), perhaps someone else can reproduce this.
Regards
Michael
--
Powered by linux-2.5.75-mm1. Compiled with gcc-2.95-3 - mature and rock solid
My current linux related activities:
- 2.5 yenta_socket testing
- Test development and testing of swsusp for 2.4/2.5 and ACPI S3 of 2.5 kernel
- Everyday usage of 2.5 kernel
More info on 2.5 kernel: http://www.codemonkey.org.uk/post-halloween-2.5.txt
More info on swsusp: http://sourceforge.net/projects/swsusp/